CVE-2026-72121: Linux Vulnerability (CVSS 8.8)

Description

In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.

Metrics

CVSS 3.1

8.8/10

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS Probability

0.33%

26.4th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 7595de7bc56e0e52b74e56c90f7e247bf626d628, < 96994180bd7b248b0cc698afe926e23fc1bda59b; >= fbd8fdc2b218e979cfe422b139b8f74c12419d1f, < caa8704a7f3cb7806331596195385437126ecb3a; >= 2a437b86ac5a9893c902f30ef66815bf13587bf6, < a7c369e7da8203e2b5be12bbcac7b9ab2ed5b658; >= 76c84c3728178b2d38d5604e399dfe8b0752645e, < a7eb6db1cd3f7b556a301dc1265945ad112089f7; >= cc55dd28c20a6611e30596019b3b2f636819a4c0, < 834cbca3b12e46887f7a9b35f1981a888360ea4c; >= c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7, < 19b1994069dd29478ba767de1f98f14a088198dc; >= c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7, < fc9f5ee1b073bd233d9c604e338af4ebb42cbc33; >= c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7, < 749179c2e25b95d22499ed29096b3e02d6dfd2b4; 8f1c022541bf5a923c8d6fa483112c15250f30a4; c4e8a172501e677ebd8ea9d9161d97dc4df56fbd; >= 5.10.238, < 5.10.265; >= 5.15.185, < 5.15.216; >= 6.1.141, < 6.1.183; >= 6.6.93, < 6.6.148; >= 6.12.31, < 6.12.101; >= 5.4.294, < 5.5; >= 6.14.9, < 6.15
Linux	Linux	6.15

References

Timeline

Published: Aug 15, 2026
Last Modified: Aug 19, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-72121?

In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.

How severe is CVE-2026-72121?

CVE-2026-72121 has a CVSS score of 8.8/10 (HIGH severity). The EPSS model estimates a 0.33% probability of exploitation in the next 30 days.

How do I fix CVE-2026-72121?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →