In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: Fix race condition in peermep deletion When a peer MEP is being deleted, canceldelayedworksync() is called on ccmrxdwork before freeing. However, brcfmframerx() runs in softirq context under rcureadlock (without RTNL) and can re-schedule ccmrxdwork via ccmrxtimerstart() between canceldelayedworksync() returning and kfreercu() being called. The following is a simple race scenario: cpu0 cpu1 mepdeleteimplementation() canceldelayedworksync(ccmrxdwork); brcfmframerx() // peermep still in hlist if (peermep->ccmdefect) ccmrxtimerstart() queuedelayedwork(ccmrxdwork) hlistdelrcu(&peermep->head); kfreercu(peermep, rcu); ccmrxworkexpired() // on freed peermep To prevent this, canceldelayedworksync() is replaced with disabledelayedworksync() in both peer MEP deletion paths, so that subsequent queuedelayedwork() calls from brcfmframerx() are silently rejected. The ccpeerdisable() helper retains canceldelayedwork_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.