CVE-2026-72123

CVE CVE-2026-72123EUVD EUVD-2026-58881Published 2026-08-15T05:53:01.000ZLast changed 2026-08-19T16:36:18.000ZCVSS 7.8

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 6.18.40; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <cd830e0bc25ee2d38cbfbdbb3cd77c5f53b2b6d5; 4.19.252 <4.20; edb4baffb9483141a50fb7f7146cfe4a4c0c2db8; f34f2a18e47b73e48f90a757e1f4aaa8c7d665a1 <036a8c320ca11bc912e8027adcfad14b326f067e; 5.10.130 <5.10.265; patch: 7.1.5; patch: 5.15.216; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <68973f9db76144825e4f35dfdc80fb8279eb2d57; 5.4.205 <5.5; fbac09a3b8890003c0c55294c00709f3ae5501bb; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <4177762f70646ac48a2af382e45a795cbd295198; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <6fd08e8d826c3aa4cc7021f5f9cdbb7fa7441d3f; patch: 0; 5.19; patch: 6.6.145; 85cd41070df992d3c0dfd828866fdd243d3b774a <de5fce46637de05bef56ec08528127676eb6fc9b; patch: 6.12.97; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <ce2d4b121fb7545e1ed588e860c8e5fd5ad45224; f1b4e32aca0811aa011c76e5d6cf2fa19224b386 <3cf4fd5316f449811d8baf1bc6978ef5a7b743a9; 5.15.54 <5.15.216; patch: 7.2; patch: 6.1.178; 5.18.11 <5.19; patch: 5.10.265; 5b48f5711f1c630841ab78dcc061de902f0e37bf

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.