Linux EUVD-2026-15394

Attacker must have low-privilege local user access on a Linux system with the bridge CFM (Connectivity Fault Management) module enabled and configured with peer MEP (Maintenance End Point) instances. Requires the ability to trigger peer MEP deletion while concurrent CCM frame reception occurs.

While CVSS and EPSS scores are not provided, the technical impact indicates a use-after-free with potential information disclosure and denial of service. The vulnerability requires local access and knowledge of CFM operations to trigger the race condition reliably, suggesting moderate attack complexity. The patch availability is confirmed via multiple stable kernel commits (e89dbd2, d8f3576, 1fd8115, 3715a00), indicating the Linux maintainers recognize this as a genuine security issue warranting backports across multiple stable series. The fix involves replacing cancel_delayed_work_sync() with disable_delayed_work_sync() in deletion paths while retaining cancel_delayed_work_sync() in enable/disable toggle paths, demonstrating precise understanding of the race window. This is not a high-CVSS-but-low-real-risk issue; rather, it is a legitimate kernel memory safety issue with clear exploitation semantics, though exploitation requires specific CFM configuration and local system access.

A local attacker with access to a system using bridge CFM for Ethernet OAM monitoring can trigger the race condition by rapidly adding and deleting peer MEP entries while CFM frames are being received on a monitored bridge interface. The attacker sends crafted CFM frames to trigger br_cfm_frame_rx() execution in softirq context while simultaneously executing netlink commands to delete peer MEPs, creating a collision where ccm_rx_timer_start() reschedules ccm_rx_dwork after cancel_delayed_work_sync() returns but before kfree_rcu() completes. When the delayed work executes on the freed peer_mep structure, it dereferences invalid memory, potentially leaking kernel address space layout information or causing a kernel panic (denial of service). No public proof-of-concept code has been reported, but the race condition is deterministic given proper timing control.