Cloudanix VulnDB

CVE-2026-93099

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel manages certain monitoring tasks during hardware changes could let a local attacker crash the system or gain higher privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in mbm_handle_overflow() and cqm_handle_limbo() delayed_work handlers when rdt_l3_mon_domain is freed during CPU hotplug while a worker holds cpus_read_lock() and later performs container_of() on the embedded work_struct after the domain memory is released.

Why it matters to the business

Systems using resctrl monitoring may experience kernel crashes, memory corruption, or local privilege escalation under CPU hotplug events, increasing downtime risk and requiring urgent kernel updates on servers with resctrl enabled.

How an attack unfolds

An attacker with local access triggers repeated CPU offline/online events while resctrl monitoring workers are active; the worker blocks on cpus_read_lock() held by cpus_write_lock() in the hotplug path, allowing the domain containing the work_struct to be freed, after which the worker resumes and dereferences freed memory via container_of().

How to fix it

Apply the upstream fix that removes cpus_read_lock() from the workers, drains pending work with cancel_delayed_work_sync() before domain free, and drops rdtgroup_mutex during offline; update to a kernel containing the resctrl domain removal synchronization changes.

How to confirm the fix worked

Confirm the patch is present by inspecting fs/resctrl/monitor.c for removal of cpus_read_lock() calls around handle functions and presence of cancel_delayed_work_sync() before domain teardown; test by exercising CPU hotplug with resctrl monitoring active and verify no UAF warnings in dmesg.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with resctrl monitoring enabled
  2. Trigger or wait for CPU hotplug events that offline L3 monitor domains
  3. Force worker scheduling via counter overflow or limbo conditions while domain removal races
  4. Cause the worker to block on cpus_read_lock() during domain free under cpus_write_lock()
  5. Resume worker execution to dereference the now-freed rdt_l3_mon_domain via work_struct

How to detect it

Inspect kernel logs for UAF or slab-use-after-free reports referencing rdt_l3_mon_domain, mbm_handle_overflow, or cqm_handle_limbo during CPU hotplug; correlate with resctrl filesystem activity and delayed_work scheduling around cpus_write_lock acquisitions.

What your security team should do

  • Prioritize kernel updates on all systems exposing resctrl monitoring interfaces
  • Disable resctrl monitoring where CPU hotplug is frequent if immediate patching is delayed
  • Monitor for kernel oops or slab corruption during CPU offline events
  • Review workloads that frequently online/offline CPUs for exposure

The record

In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.

Affected packages

Ecosystem Package Introduced Fixed