Cloudanix VulnDB

CVE-2026-99065

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel's handling of CPU changes can cause servers to crash unexpectedly when CPUs are added or removed.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition during CPU offline allows cpu_active_mask update to precede cpuset_handle_hotplug, leaving top cpuset with no active CPUs; guarantee_active_cpus then dereferences NULL when called in the race window.

Why it matters to the business

Linux systems performing CPU hotplug operations can experience kernel crashes or denial of service, disrupting workloads on servers and cloud instances until the kernel is updated.

How an attack unfolds

An attacker with local access or the ability to trigger CPU offline events forces the timing window between sched_cpu_deactivate updating cpu_active_mask and cpuset_handle_hotplug updating effective_cpus, causing guarantee_active_cpus to hit a NULL cs pointer and panic the kernel.

How to fix it

Apply the upstream fix that restores the NULL cs check in guarantee_active_cpus; rebuild and deploy the patched kernel on all affected Linux distributions.

How to confirm the fix worked

Verify the NULL cs guard is present in the running kernel's cpuset.c; perform controlled CPU offline tests and confirm no NULL dereference occurs in guarantee_active_cpus.

Typical attack path

  1. Obtain local execution or control over CPU hotplug events
  2. Initiate CPU offline operation
  3. Time the operation to occur between cpu_active_mask update and cpuset hotplug work
  4. Trigger guarantee_active_cpus call during the window to dereference NULL and crash the kernel

How to detect it

Search kernel logs and crash dumps for NULL pointer dereference in guarantee_active_cpus or cpuset hotplug paths around CPU offline events.

  • guarantee_active_cpus
  • cpuset_handle_hotplug
  • cpu_active_mask
  • NULL pointer dereference.*cpuset

What your security team should do

  • Prioritize kernel updates on systems that perform dynamic CPU hotplug
  • Monitor for kernel oops reports referencing cpuset or guarantee_active_cpus
  • Restrict unprivileged local access until patches are applied

The record

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.

Affected packages

Ecosystem Package Introduced Fixed