CVE-2026-72010 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed
Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event.
Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold()
The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path.
[ david: add a comment, slightly rephrase description ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
This vulnerability exists in the Linux kernel's cpuset subsystem where improper handling of memory policy rebinding during CPU hotplug events can lead to a division by zero error. The flaw occurs specifically when a child cpuset is created without explicitly setting the cpuset.mems parameter, creating an inconsistent state that becomes problematic during memory policy operations. The vulnerability stems from the kernel's memory management subsystem where the mpol_relative_nodemask function attempts to perform division operations on nodemask values that may be empty or improperly initialized.
The technical implementation issue manifests when a Virtual Memory Area (VMA) memory policy with the MPOL_F_RELATIVE_NODES flag is established for tasks within a cpuset that has not had its mems_allowed parameter explicitly configured. During CPU hotplug events, the system attempts to rebind memory policies, but the code path incorrectly passes the cs->mems_allowed value to the rebind routine. This parameter may be empty or contain invalid nodemask data when the cpuset was created without explicit memory node configuration, leading to a division by zero condition in the __nodes_fold() function call.
The operational impact of this vulnerability is significant as it can cause kernel panics and system crashes when CPU hotplug events occur in environments where cpusets are used for resource management. This affects systems running containerized workloads, virtualization platforms, and any environment utilizing Linux cgroup memory management features where tasks may be moved between cpusets during runtime operations. The vulnerability particularly impacts systems that dynamically adjust CPU configurations or employ automated scaling mechanisms that trigger hotplug events.
The root cause aligns with CWE-369: Division by Zero, where the kernel fails to validate nodemask contents before performing mathematical operations. This vulnerability also maps to ATT&CK technique T1490: Inhibit System Recovery, as it can lead to system instability and potential denial of service conditions. The fix implements a proper validation approach by ensuring that cs->effective_mems is used instead of cs->mems_allowed, since effective_mems is guaranteed to contain valid non-empty nodemask data when reaching the rebind code path. This change ensures proper initialization of memory policy structures before mathematical operations are performed.
Mitigation strategies include applying the kernel patch that corrects the memory policy rebind logic by using the guaranteed non-empty effective_mems parameter instead of potentially empty mems_allowed values. System administrators should ensure all cpuset configurations properly initialize memory node specifications to avoid triggering this code path. Monitoring for CPU hotplug events in containerized environments and implementing proper resource isolation can help minimize exposure. Additionally, maintaining up-to-date kernel versions that include this fix is essential as the vulnerability affects core memory management functionality within the Linux kernel's cgroup subsystem.
This vulnerability demonstrates the complexity of memory policy handling in multi-core systems where CPU hotplug operations interact with process memory allocation strategies. The issue highlights the importance of proper parameter validation in kernel space code and the potential for seemingly minor configuration omissions to trigger critical system failures. The fix represents a defensive programming approach that ensures all data structures are properly initialized before mathematical operations, preventing the conditions that lead to kernel panic scenarios during dynamic CPU management events.