CVE-2026-23393
Received Received - Intake
Race Condition in Linux Kernel Bridge CFM Peer MEP Deletion

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23393
EUVD
EUVD-2026-15394
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.11
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.20 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.10 (exc)
linux linux_kernel From 5.11.1 (inc) to 6.12.78 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's bridge component related to the deletion of a peer MEP (Maintenance End Point) in the Connectivity Fault Management (CFM) feature.

When a peer MEP is deleted, the system calls cancel_delayed_work_sync() on a delayed work item (ccm_rx_dwork) before freeing the peer MEP. However, another function, br_cfm_frame_rx(), running in a softirq context, can reschedule this delayed work between the cancellation and the actual freeing of the peer MEP.

This leads to a race where the delayed work might run on a peer MEP that has already been freed, causing potential use-after-free issues.

The fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync() during peer MEP deletion to silently reject any rescheduling attempts after cancellation, preventing the race condition.


How can this vulnerability impact me? :

This race condition can lead to use-after-free scenarios where the system might access memory that has already been freed.

Such issues can cause system instability, crashes, or potentially allow attackers to execute arbitrary code or cause denial of service by exploiting the improper memory handling.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by replacing cancel_delayed_work_sync() with disable_delayed_work_sync() in the peer MEP deletion paths to prevent race conditions.

Therefore, the immediate mitigation step is to update your Linux kernel to a version where this fix has been applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart