CVE-2023-52831 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
cpu/hotplug: Don't offline the last non-isolated CPU
If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/20/2026
This vulnerability exists in the Linux kernel's CPU hotplug functionality where the system fails to properly handle the scenario of offlining the last non-isolated CPU when isolated CPUs are configured through the "isolcpus=" parameter. The issue stems from a logical flaw in the scheduler domain rebuilding process that occurs during CPU hotplug operations. When the system attempts to offline a CPU that is the last housekeeping CPU in an isolated configuration, the kernel triggers a WARN_ON() condition in the scheduler domain building logic, leading to an unhandled empty CPU mask that ultimately causes a kernel panic. The vulnerability manifests specifically during the cpuset_hotplug_workfn() function execution, where rebuild_sched_domains_locked() is called, and subsequently calls partition_sched_domains_locked() which encounters an empty CPU mask that cannot be handled gracefully.
The technical root cause involves the interaction between multiple kernel subsystems including CPU hotplug management, scheduler topology, and cpuset functionality. The problematic code path begins with cpuset_hotplug_workfn() which invokes rebuild_sched_domains_locked(), leading to generate_sched_domains() that uses cpumask_and() to intersect housekeeping_cpumask(HK_FLAG_DOMAIN) with top_cpuset.effective_cpus. When all non-isolated CPUs are removed, this intersection results in an empty CPU mask, causing the kernel to panic in partition_sched_domains_locked() at line 2366 of topology.c. This represents a classic case of improper input validation where the kernel does not account for edge cases involving isolated CPU configurations. The vulnerability is classified as a denial of service condition that can lead to complete system instability.
The operational impact of this vulnerability is significant for systems that rely on CPU isolation for performance isolation or security purposes, particularly in virtualized environments or real-time systems. Systems configured with isolated CPUs through the isolcpus parameter are at risk of crashing when attempting to offline the last housekeeping CPU, potentially leading to complete system downtime. This vulnerability affects kernel versions that implement the cpuset and scheduler domain management functionality, particularly those supporting CPU hotplug operations. The crash occurs during runtime when CPU hotplug events are processed, making it particularly dangerous in production environments where system stability is critical. Attackers could potentially exploit this by triggering CPU hotplug operations on systems with isolated CPUs, leading to denial of service conditions.
The mitigation strategy involves modifying the CPU unplug operation to prevent attempts to offline the last housekeeping CPU in isolated configurations. The solution requires updating the CPU hotplug logic to properly mask out non-housekeeping CPUs when selecting target CPUs for unplug operations via the work queue mechanism. This approach aligns with the principle of least privilege and proper resource management, ensuring that system-critical housekeeping CPUs remain online when they are the last functional CPUs in a given domain. The fix implements a validation check before initiating CPU unplug operations to ensure that housekeeping CPUs are not offlined when they represent the last available CPU in their respective scheduling domains. This vulnerability demonstrates the importance of considering edge cases in kernel-level resource management and aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and ATT&CK technique T1490 (Inhibit System Recovery) through its potential to cause system instability and denial of service conditions.