CVE-2026-72123: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF

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

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

Commit f1b4e32aca08 ("can: bcm: use callrcu() instead of costly synchronizercu()") replaced synchronizercu() in bcmdeleterxop() with callrcu() and introduced the RXNOAUTOTIMER flag.

However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcmrxhandler) can race and re-arm thrtimer via bcmrxupdateandsend() after callrcu() has been scheduled. Once the RCU grace period elapses, bcmop is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF.

Adding flag checks to the rx fast-path (bcmrxupdateandsend) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimercancel() directly inside the RCU callback (softirq context) is fatal as hrtimercancel() can sleep, triggering a "scheduling while atomic" panic.

Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcmwq). The RCU callback now queues a work item to bcmwq, 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 (bcmsendtouser()) dereferences op->sk.