Linux Kernel Race Condition Vulnerability in Bridge CFM Peer MEP Deletion

A race condition vulnerability has been identified in the Linux kernel's bridge component, specifically within the CFM (Connectivity Fault Management) implementation. This issue arises when a peer MEP (Maintenance Endpoint) is deleted. The process first calls 'cancel_delayed_work_sync()' on the 'ccm_rx_dwork' (CCM receive work) before freeing the MEP. However, the function 'br_cfm_frame_rx()' operates in a softirq context under RCU (Read-Copy-Update) read lock, without holding the RTNL (Route Netlink) lock. This allows 'br_cfm_frame_rx()' to reschedule 'ccm_rx_dwork' via 'ccm_rx_timer_start()' after 'cancel_delayed_work_sync()' has returned, but before 'kfree_rcu()' is executed, creating a race condition. The vulnerability affects the Linux kernel stable tree.

Impact

The vulnerability can lead to a use-after-free condition, where a peer MEP is accessed after it has been freed, potentially causing memory corruption or instability in the system.

Reproduction

To reproduce this vulnerability, initiate the deletion of a peer MEP in the bridge CFM implementation. While the deletion process is ongoing, 'br_cfm_frame_rx()' can be triggered to run in a softirq context. This function can reschedule the 'ccm_rx_dwork' work item before the MEP is fully freed, creating a race condition. Once the 'ccm_rx_work_expired()' function is called, it will attempt to access the already freed MEP, demonstrating the vulnerability.

Remediation

The vulnerability has been addressed by replacing 'cancel_delayed_work_sync()' with 'disable_delayed_work_sync()' in the peer MEP deletion process. This change prevents 'br_cfm_frame_rx()' from rescheduling the work item after it has been marked for deletion.