The flaw manifests when an ANYDEV receive operation (identified by a zero interface index) is subject to an active RX timeout or throttle timer and receives frames from multiple physical interfaces. The bcm_rx_handler routine can run concurrently on separate CPUs, racing against hrtimer_cancel, bcm_rx_starttimer, and bcm_rx_timeout_handler. This race leads to unsynchronized updates of shared timer structures and frame data, producing spurious RX_TIMEOUT notifications and corrupting the last_frames buffer. The result is degraded reliability of CAN bus communication and the possibility of corrupted or lost frames.

All Linux kernel builds that include the buggy bcm driver code before the introduction of the op->if_detected field are affected. The issue is present in any kernel that has not yet incorporated the commit that adds the claim logic, regardless of distribution. The affected vendor is Linux, product Linux kernel, with no explicit version range supplied in the CNA data.

The CVSS score is 8.1, the EPSS score is less than 1%, and the vulnerability is not listed in the CISA KEV catalog. The race condition is local in nature; an attacker would need the ability to inject frames on a CAN bus managed by the kernel. While no public exploit is known, the combination of a race condition and shared timer state raises the likelihood of a successful denial of service or corruption attack in environments where the attacker can influence CAN traffic or where the affected driver manages critical traffic.