CVE-2026-23393: bridge: cfm: Fix race condition in peer_mep deletion
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, cancel_delayed_work_sync() is called
on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in
softirq context under rcu_read_lock (without RTNL) and can re-schedule
ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()
returning and kfree_rcu() being called.
The following is a simple race scenario:
cpu0 cpu1
mep_delete_implementation()
cancel_delayed_work_sync(ccm_rx_dwork);
br_cfm_frame_rx()
// peer_mep still in hlist
if (peer_mep->ccm_defect)
ccm_rx_timer_start()
queue_delayed_work(ccm_rx_dwork)
hlist_del_rcu(&peer_mep->head);
kfree_rcu(peer_mep, rcu);
ccm_rx_work_expired()
// on freed peer_mep
To prevent this, cancel_delayed_work_sync() is replaced with
disable_delayed_work_sync() in both peer MEP deletion paths, so
that subsequent queue_delayed_work() calls from br_cfm_frame_rx()
are silently rejected.
The cc_peer_disable() helper retains cancel_delayed_work_sync()
because it is also used for the CC enable/disable toggle path where
the work must remain re-schedulable.
Security readout for executives and security teams
Plain-English summary
A timing flaw in Linux bridge Connectivity Fault Management can let scheduled work run after a peer maintenance endpoint is freed. A successful local attack could compromise confidentiality, integrity, and availability. The source bundle rates it CVSS 7.8, but does not establish remote reachability or exploitation in the wild.
Executive priority
Treat as a high-priority kernel maintenance issue on exposed bridge-CFM systems, especially multi-user or locally accessible hosts. Patch those systems promptly through supported distribution channels. Broader emergency action is not supported by the evidence because remote reachability and active exploitation are not established.
Technical view
During peer MEP deletion, receive processing can requeue ccm_rx_dwork after cancellation but before RCU freeing, producing a use-after-free. The kernel fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync() in both deletion paths, rejecting later queue attempts while preserving rescheduling behavior for the separate enable/disable path.
Likely exposure
Exposure is most likely on affected Linux systems using bridge CFM peer MEP functionality. The CVSS vector requires local access and low privileges. The bundle identifies Linux 5.11 and several later version points as affected, but its version encoding does not provide sufficiently clear branch ranges for definitive fleet matching.
Exploitation context
No active exploitation is established: the bundle marks KEV false and supplies no cited exploitation report. Exploitation would require winning a narrow deletion-versus-requeue race and reaching the relevant local kernel functionality. Practical reliability, required configuration, and attack prerequisites beyond the CVSS vector are not documented in the supplied sources.
Researcher notes
The defect is an RCU/workqueue lifetime race: softirq receive handling retains visibility of peer_mep and can queue delayed work between synchronous cancellation and hlist removal/freeing. Disabling delayed work closes that window by rejecting requeues. The supplied sources do not identify a CWE, demonstrate exploitability, or map each stable commit to an exact release range.
Mitigation direction
Apply a vendor-supported kernel update containing the referenced stable fix for your kernel branch.
Prioritize systems using Linux bridge CFM or configured peer maintenance endpoints.
Check distribution advisories for exact affected and fixed package versions.
Where patching is delayed, restrict local access and disable unused bridge CFM functionality after operational review.
Validation and detection
Inventory kernel versions and identify hosts using bridge CFM peer MEP functionality.
Confirm the installed vendor kernel includes the applicable referenced stable commit.
Review vendor advisories because the supplied affected-version data lacks clear branch boundaries.
After updating, verify the new kernel is running and bridge operations remain healthy.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23393 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.