CVE-2026-72123: Linux Vulnerability (CVSS 7.8)

Description

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.

Metrics

CVSS 3.1

7.8/10

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

EPSS Probability

0.16%

6.1th 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	>= 85cd41070df992d3c0dfd828866fdd243d3b774a, < de5fce46637de05bef56ec08528127676eb6fc9b; >= f34f2a18e47b73e48f90a757e1f4aaa8c7d665a1, < 036a8c320ca11bc912e8027adcfad14b326f067e; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < 3cf4fd5316f449811d8baf1bc6978ef5a7b743a9; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < 4177762f70646ac48a2af382e45a795cbd295198; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < 6fd08e8d826c3aa4cc7021f5f9cdbb7fa7441d3f; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < cd830e0bc25ee2d38cbfbdbb3cd77c5f53b2b6d5; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < ce2d4b121fb7545e1ed588e860c8e5fd5ad45224; >= f1b4e32aca0811aa011c76e5d6cf2fa19224b386, < 68973f9db76144825e4f35dfdc80fb8279eb2d57; fbac09a3b8890003c0c55294c00709f3ae5501bb; 5b48f5711f1c630841ab78dcc061de902f0e37bf; edb4baffb9483141a50fb7f7146cfe4a4c0c2db8; >= 5.10.130, < 5.10.265; >= 5.15.54, < 5.15.216; >= 4.19.252, < 4.20; >= 5.4.205, < 5.5; >= 5.18.11, < 5.19
Linux	Linux	5.19

References

Timeline

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

Frequently Asked Questions

What is CVE-2026-72123?

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.

How severe is CVE-2026-72123?

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

How do I fix CVE-2026-72123?

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 →