CVE-2026-72123

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

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF

Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly

synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op()

with call_rcu() and introduced the RX_NO_AUTOTIMER flag.

However, this flag check was omitted for thrtimer in the packet rx

fast-path. During BCM RX operation teardown, a concurrent RCU reader

(bcm_rx_handler) can race and re-arm thrtimer via

bcm_rx_update_and_send() after call_rcu() has been scheduled. Once

the RCU grace period elapses, bcm_op is freed. The subsequently

firing thrtimer then dereferences the deallocated op, causing a UAF.

Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not

fully close the TOCTOU race and introduces latency for every CAN frame.

Conversely, calling hrtimer_cancel() directly inside the RCU callback

(softirq context) is fatal as hrtimer_cancel() can sleep, triggering

a "scheduling while atomic" panic.

Resolve this by deferring the timer cancellation and memory free to a

dedicated unbound workqueue (bcm_wq). The RCU callback now queues a

work item to bcm_wq, which safely cancels both timers and deallocates

memory in sleepable process context. A dedicated workqueue is used to

prevent system-wide WQ saturation and is cleanly flushed/destroyed

on module unload to avoid rmmod page faults.

Since the deferred work can now outlive the calling context by an

unbounded amount, also take a reference on op->sk when it is assigned

and drop it only once the deferred work has cancelled both timers, so a

socket can no longer be freed out from under a still-armed timer whose

callback (bcm_send_to_user()) dereferences op->sk. (NVD)

What to Do

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

References