CVE-2026-99065 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()
With commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset hotplug operation becomes synchronous. That commit also removes the code that handles race between cpuset_hotplug_work and cpu hotplug notifier with the assumption that race is now gone. Later commit 7a0aabd9ce69 ("cgroup/cpuset: Always use cpu_active_mask") updates the cpuset code to always use cpu_active_mask instead of cpu_online_mask in some places including guarantee_online_cpus() which is renamed to guarantee_active_cpus() in that commit.
In the case of CPU offline operation, cpu_active_mask is updated first in sched_cpu_deactivate() to remove the offline CPU before cpuset_handle_hotplug() is called to update the effective_cpus of the affected cpusets. The cpu_online_mask is updated after that near the end of the offline operation to remove the offline CPU. As a result, the race comes back and the top cpuset may not have any active CPU leading to NULL pointer dereference during the race window when guarantee_active_cpus() is called after cpu_active_mask is updated to remove the CPU to be torn down but before cpuset_handle_hotplug() is able to properly update the effective_cpus of the top cpuset.
Fix this by adding back the NULL cs check to avoid this problem.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel cgroup subsystem contains a critical race condition within the cpuset management logic, specifically in the guarantee_active_cpus function. This vulnerability arises from an interaction between CPU hotplug operations and the synchronization mechanisms intended to manage processor availability for control groups. The issue stems from historical changes where commit 2125c0034c5d attempted to make cpuset hotplug processing synchronous by removing code that previously handled races between cpuset_hotplug_work and cpu hotplug notifiers under the assumption that such races were eliminated. Subsequently, commit 7a0aabd9ce69 modified the cpuset code to consistently utilize the cpu_active_mask rather than the cpu_online_mask in various contexts, including renaming guarantee_online_cpus to guarantee_active_cpus. However, this transition inadvertently reintroduced a race condition during CPU offline operations due to the specific ordering of mask updates and handler invocations.
During a CPU offline operation, the kernel first updates the cpu_active_mask via sched_cpu_deactivate to logically remove the offline CPU from the set of active processors before invoking cpuset_handle_hotplug to update the effective_cpus for affected cpusets. The cpu_online_mask is updated later in the sequence near the end of the offline process. This ordering creates a narrow window where guarantee_active_cpus may be called after the cpu_active_mask has been modified to exclude the CPU being torn down, but before cpuset_handle_hotplug has had the opportunity to properly adjust the effective_cpus of the top-level cpuset. In this specific state, the top cpuset may temporarily appear to have no active CPUs available for scheduling tasks.
The operational impact of this race condition is severe, leading to a NULL pointer dereference within the kernel space. When guarantee_active_cpus determines that there are no active CPUs in the target cpuset due to the timing mismatch described above, it fails to handle the empty state correctly, resulting in a crash or system instability. This vulnerability affects systems relying on dynamic CPU management and cgroup-based resource isolation, potentially causing denial of service through kernel panics if triggered by rapid CPU hotplug events combined with concurrent scheduling decisions that invoke guarantee_active_cpus during the vulnerable window.
From a classification perspective, this flaw aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as it involves a race condition between multiple execution paths modifying shared state without adequate synchronization barriers to prevent inconsistent intermediate states. It also relates to CWE-476, NULL Pointer Dereference, which is the direct consequence of failing to check for null conditions when resources are unexpectedly unavailable. In terms of adversarial tactics, this could be leveraged in an ATT&CK context under T1053 Scheduled Task/Job or T1059 Command and Scripting Interpreter if exploited via local privilege escalation following a kernel crash that leads to memory corruption or state inconsistency, although the primary impact is stability rather than direct exploitation for code execution.
To mitigate this vulnerability, it is essential to apply the upstream Linux kernel patch that restores the NULL check within guarantee_active_cpus. This fix ensures that even when the race condition occurs and no active CPUs are detected in the cpuset, the function handles the situation gracefully without dereferencing a null pointer. System administrators should ensure their kernels are updated with this specific correction. Additionally, monitoring for CPU hotplug events and ensuring stable system configurations during maintenance windows can reduce the likelihood of triggering this edge case until all systems are patched. Regular kernel updates and adherence to vendor security advisories remain the primary defense against such low-level synchronization flaws in operating system core components.