CVE-2026-72121

Status: UPDATED  |  Advisory ID: CVE-2026-72121

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References