DEBIAN-CVE-2026-23393

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.