CVE-2026-72123 Affecting kernel-uek-debug-modules-extra package, versions <0:6.12.0-206.104.3.3.el10uek


Severity

Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.16% (7th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-ORACLE10-KERNELUEKDEBUGMODULESEXTRA-19568580
  • published5 Sept 2026
  • disclosed15 Aug 2026

Introduced: 15 Aug 2026

NewCVE-2026-72123  (opens in a new tab)

How to fix?

Upgrade Oracle:10 kernel-uek-debug-modules-extra to version 0:6.12.0-206.104.3.3.el10uek or higher.
This issue was patched in ELSA-2026-500248.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-debug-modules-extra package and not the kernel-uek-debug-modules-extra package as distributed by Oracle. See How to fix? for Oracle:10 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1