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.
Published: 2026-08-15
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The bug occurs when the bcm driver releases a receive operation (rx_op) by scheduling an RCU callback that frees the op without checking the new RX_NO_AUTOTIMER flag in the timer path. A concurrent CAN frame handler can re‑arm the high‑resolution timer before the old op is freed, causing the timer to fire and dereference the deallocated memory. This results in a use‑After‑Free that can give an attacker the ability to execute arbitrary code or crash the kernel.

Affected Systems

The vulnerability affects the Linux kernel CAN bus driver, specifically the bcm module. No specific kernel versions are listed in the data; the fix was introduced in commit f1b4e32aca08. Systems running a kernel that includes this commit, or any later kernel that implements the described workqueue‑based deallocation, are not affected. Administrators should verify whether their current kernel includes the commit or newer revisions of the bcm driver.

Risk and Exploitability

Exploitability requires a race between a CAN frame handler and a timer, implying that an attacker must be able to inject crafted CAN traffic or have privileged access to the system. The EPSS score is < 1% and the vulnerability is not listed in the CISA KEV catalog. Without a publicly known exploit, the risk is considered high for systems that actively process CAN traffic, especially if the attacker can drive a sustained race condition leading to a use‑After‑Free. The CVSS score of 7.8 indicates a medium‑to‑high severity vulnerability capable of granting kernel‑level code execution if exploited.

Generated by OpenCVE AI on August 18, 2026 at 02:47 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that contains commit f1b4e32aca08 or newer, ensuring that the bcm driver performs timer cancellation and memory deallocation in a workqueue rather than in interrupt context.
  • If the CAN subsystem is not required, remove or blacklist the bcm module by updating the kernel configuration or ~/.config/modules, thereby eliminating the attack surface.
  • Monitor system logs for scheduling panics or anomalous can driver activity; any such incidents should be investigated as possible exploitation attempts.

Generated by OpenCVE AI on August 18, 2026 at 02:47 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 19 Aug 2026 16:45:00 +0000


Tue, 18 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-364
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 17 Aug 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 15 Aug 2026 09:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
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.
Title can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-19T16:36:18.988Z

Reserved: 2026-08-09T03:40:39.907Z

Link: CVE-2026-72123

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:21:29.577

Modified: 2026-08-19T17:20:59.547

Link: CVE-2026-72123

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72123 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-18T03:00:09Z

Weaknesses
  • CWE-364

    Signal Handler Race Condition