CVE-2026-23393

In the Linux kernel, the following vulnerability has been resolved:

bridge: cfm: Fix race condition in peer_mep 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 kfree_rcu() 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 peer_mep

To prevent this, canceldelayedworksync() is replaced with disabledelayedworksync() in both peer MEP deletion paths, so that subsequent queuedelayedwork() calls from brcfmframe_rx() 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.