CVE-2026-98972 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode()
After seeing the patch [1] to guard is_in_v2_mode() with RCU, it makes
me realize that is_in_v2_mode() may be called in a context where a new cgroup filesystem is being rebound with stale cpuset_cgrp_subsys.root pointer. Avoid this potential UaF situation by adding a new cpuset_v2_mode flag which is set when the cpuset_v2_mode mount option is used. This flag is written into only when cpuset_bind() is being called with a stable cpuset_cgrp_subsys.root value. The is_in_v2_mode() helper is modified to read the new cpuset_v2_mode flag instead of accessing cpuset_cgrp_subsys.root directly.
[1] https://lore.kernel.org/lkml/[email protected]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's control group subsystem, specifically the cpuset implementation, contained a critical race condition vulnerability related to memory safety during filesystem rebinding operations. The core issue stemmed from the is_in_v2_mode helper function, which was designed to determine whether the system was operating in cgroup v2 mode by directly accessing the cpuset_cgrp_subsys.root pointer. While previous patches attempted to mitigate concurrency issues by guarding this access with Read-Copy-Update mechanisms, a deeper architectural flaw remained. During the process of rebinding a new cgroup filesystem, there exists a transient window where the old root structure is being dismantled while the new one is not yet fully stabilized. In this specific context, accessing cpuset_cgrp_subsys.root could result in reading stale or freed memory addresses because the pointer might be dereferenced after its underlying data structures have been released but before they are completely zeroed out or replaced by a valid reference.
This vulnerability represents a classic Use-After-Free scenario where kernel code attempts to access memory that has already been deallocated. The operational impact of this flaw is significant, as it can lead to unpredictable system behavior ranging from minor data corruption to severe kernel panics and system crashes. In more sophisticated attack scenarios, an attacker with local privileges could potentially exploit this race condition to execute arbitrary code within the kernel space by manipulating memory contents at the specific moment when the stale pointer is accessed. The vulnerability highlights the complexity of managing shared state in concurrent environments, particularly when dealing with subsystems that undergo dynamic reconfiguration such as cgroup filesystem mounts and unmounts.
To resolve this issue, developers introduced a dedicated cpuset_v2_mode flag within the kernel data structures. This approach decouples the mode detection logic from direct pointer dereferencing of the root structure. The new flag is set exclusively during the cpuset_bind operation, which occurs when the subsystem is attached to a cgroup hierarchy and has access to a stable and valid cpuset_cgrp_subsys.root value. By writing this boolean state only at points where memory safety is guaranteed, the kernel ensures that subsequent calls to is_in_v2_mode simply read this flag rather than traversing potentially unstable pointers. This change eliminates the race window entirely by ensuring that the mode determination relies on a stable variable updated under proper synchronization constraints rather than relying on RCU guards alone for pointer validity during rebinding transitions.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free and CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization Race Condition. The mitigation strategy reflects best practices in kernel development by avoiding direct access to shared resources during state changes and instead utilizing explicit flags that are updated under controlled conditions. Security practitioners should ensure their systems are patched with the latest Linux kernel versions containing this fix. Additionally, organizations relying on cgroup v2 features for container isolation and resource management must verify that their deployment pipelines apply these updates promptly to prevent potential denial of service or privilege escalation attacks stemming from this race condition in the cpuset subsystem.