CVE-2026-23393 Overview
A race condition vulnerability has been identified in the Linux kernel's bridge Connectivity Fault Management (CFM) subsystem. The flaw exists in the peer MEP (Maintenance End Point) deletion process, where improper synchronization between the deletion routine and frame reception can lead to use-after-free conditions. When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing the structure. 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.
Critical Impact
This race condition can result in use-after-free access when the delayed work executes on a freed peer_mep structure, potentially leading to kernel memory corruption, denial of service, or privilege escalation.
Affected Products
- Linux kernel (bridge CFM subsystem)
- Systems utilizing bridge connectivity fault management features
- Network infrastructure components running affected kernel versions
Discovery Timeline
- 2026-03-25 - CVE CVE-2026-23393 published to NVD
- 2026-03-25 - Last updated in NVD database
Technical Details for CVE-2026-23393
Vulnerability Analysis
This vulnerability is classified as a Race Condition and Use After Free in the Linux kernel bridge CFM module. The issue arises from improper synchronization in the mep_delete_implementation() function when deleting peer MEP structures. The race window exists because frame reception processing in br_cfm_frame_rx() operates under RCU read lock without RTNL protection, allowing concurrent access to the peer MEP structure during the deletion sequence.
The fundamental problem is that cancel_delayed_work_sync() only cancels pending or running work, but does not prevent the work from being re-queued after it returns. When br_cfm_frame_rx() processes a CCM frame and detects the peer MEP is still present in the hash list (before hlist_del_rcu() executes), it can call ccm_rx_timer_start() which queues the delayed work again. This newly queued work will then execute after kfree_rcu() has freed the peer MEP structure, resulting in a use-after-free condition.
Root Cause
The root cause is the use of cancel_delayed_work_sync() in the peer MEP deletion path, which only cancels existing scheduled work but does not prevent subsequent re-scheduling. The br_cfm_frame_rx() function runs in softirq context and can re-arm the ccm_rx_dwork delayed work after the cancellation but before the RCU-protected free operation completes. The fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync() in both peer MEP deletion paths, which prevents any subsequent queue_delayed_work() calls from succeeding.
Attack Vector
The attack vector involves triggering the race condition between peer MEP deletion operations and CFM frame reception processing. An attacker would need to:
- Identify a system using the Linux kernel bridge CFM functionality
- Generate CFM CCM frames targeting a peer MEP that is being deleted
- Time the frame transmission to arrive between cancel_delayed_work_sync() completion and kfree_rcu() execution
- The ccm_rx_work_expired() callback will then operate on freed memory
The race scenario as documented in the kernel patch demonstrates the timing window:
On CPU0, mep_delete_implementation() calls cancel_delayed_work_sync(ccm_rx_dwork). Before CPU0 can execute hlist_del_rcu() and kfree_rcu(), CPU1 processes br_cfm_frame_rx(), finds the peer_mep still in the hash list, and if peer_mep->ccm_defect is set, calls ccm_rx_timer_start() which re-queues the delayed work. CPU0 then completes the deletion and frees the structure. Subsequently, ccm_rx_work_expired() runs on CPU1, accessing the freed peer_mep structure.
Detection Methods for CVE-2026-23393
Indicators of Compromise
- Kernel oops or panic messages referencing ccm_rx_work_expired or bridge CFM functions
- Slab corruption warnings related to network subsystem structures
- Unexpected system crashes or hangs when network bridge CFM operations are active
- KASAN (Kernel Address Sanitizer) reports indicating use-after-free in bridge CFM code
Detection Strategies
- Enable KASAN (Kernel Address Sanitizer) in development/test environments to detect use-after-free conditions
- Monitor kernel logs for oops or BUG() messages involving br_cfm or ccm_rx function names
- Deploy kernel tracing to monitor delayed work queue operations on systems using bridge CFM
- Implement system monitoring for unexpected kernel crashes correlating with CFM traffic patterns
Monitoring Recommendations
- Configure dmesg log forwarding to a central SIEM for kernel message analysis
- Enable slab debugging (CONFIG_DEBUG_SLAB) on non-production systems to detect memory corruption
- Monitor system stability metrics on hosts running bridge CFM configurations
- Set up alerts for kernel oops events, particularly those involving network bridge components
How to Mitigate CVE-2026-23393
Immediate Actions Required
- Update the Linux kernel to a patched version containing the fix
- Review systems for bridge CFM usage and prioritize patching for affected hosts
- Consider temporarily disabling CFM functionality on critical systems until patches can be applied
- Monitor affected systems for signs of exploitation or instability
Patch Information
The fix has been committed to the stable Linux kernel tree. The patch replaces cancel_delayed_work_sync() with disable_delayed_work_sync() in the peer MEP deletion paths, ensuring that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected rather than re-scheduling work on a structure about to be freed. The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is used for the CC enable/disable toggle path where the work must remain re-schedulable.
Kernel patches are available via:
- Kernel Git Commit 1fd81151f659
- Kernel Git Commit 3715a0085531
- Kernel Git Commit d8f35767bacb
- Kernel Git Commit e89dbd2736a4
Workarounds
- Disable bridge CFM functionality if not required for operations
- Restrict access to systems using bridge CFM to trusted network segments
- Implement network segmentation to limit exposure of systems running affected configurations
- Apply kernel live patching solutions if available for your distribution
# Check if bridge CFM module is loaded
lsmod | grep br_netfilter
# Review bridge configuration for CFM usage
bridge link show
# Disable CFM on bridge interface if not needed (example)
# Consult your distribution documentation for proper bridge CFM configuration
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
