CVE-2024-36888 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Fix selection of wake_cpu in kick_pool()
With cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following kernel oops was observed:
smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 8 CPUs Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000803 [..]
Call Trace: arch_vcpu_is_preempted+0x12/0x80 select_idle_sibling+0x42/0x560 select_task_rq_fair+0x29a/0x3b0 try_to_wake_up+0x38e/0x6e0 kick_pool+0xa4/0x198 __queue_work.part.0+0x2bc/0x3a8 call_timer_fn+0x36/0x160 __run_timers+0x1e2/0x328 __run_timer_base+0x5a/0x88 run_timer_softirq+0x40/0x78 __do_softirq+0x118/0x388 irq_exit_rcu+0xc0/0xd8 do_ext_irq+0xae/0x168 ext_int_handler+0xbe/0xf0 psw_idle_exit+0x0/0xc default_idle_call+0x3c/0x110 do_idle+0xd4/0x158 cpu_startup_entry+0x40/0x48 rest_init+0xc6/0xc8 start_kernel+0x3c4/0x5e0 startup_continue+0x3c/0x50
The crash is caused by calling arch_vcpu_is_preempted() for an offline CPU. To avoid this, select the cpu with cpumask_any_and_distribute() to mask __pod_cpumask with cpu_online_mask. In case no cpu is left in the pool, skip the assignment.
tj: This doesn't fully fix the bug as CPUs can still go down between picking the target CPU and the wake call. Fixing that likely requires adding cpu_online() test to either the sched or s390 arch code. However, regardless of how that is fixed, workqueue shouldn't be picking a CPU which isn't online as that would result in unpredictable and worse behavior.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2025
The vulnerability described in CVE-2024-36888 represents a critical kernel-level issue within the Linux workqueue subsystem that manifests as a kernel oops during system boot or CPU online/offline operations. This flaw occurs specifically when the kernel attempts to wake up a CPU that is not actually online, leading to a pointer dereference error in the virtual kernel address space. The issue is particularly significant in systems where the possible CPU mask spans 0-63 while the online CPU mask only includes 0-7, creating a scenario where the workqueue subsystem incorrectly selects an offline CPU for wake operations.
The technical root cause stems from the kick_pool() function in the workqueue implementation which fails to properly validate CPU availability before attempting to wake a target CPU. When the kernel processes CPU bring-up operations and encounters a situation where cpu_possible_mask encompasses more CPUs than cpu_online_mask, the selection mechanism in kick_pool() does not adequately filter against the online CPU set. This results in arch_vcpu_is_preempted() being called on an offline CPU, causing the kernel to attempt dereferencing a null pointer at address 0x0000000000000000. The call trace demonstrates this progression from the initial workqueue operation through to the final kernel oops, highlighting the failure point in the scheduling and wake-up mechanism.
The operational impact of this vulnerability extends beyond simple system crashes, potentially leading to system instability and denial of service conditions during critical boot phases or dynamic CPU management operations. The vulnerability affects systems running Linux kernels where the workqueue subsystem handles timer-based operations and CPU wake-up requests, particularly impacting s390 architecture systems given the specific mention of s390 architecture code in the analysis. This flaw demonstrates a fundamental issue in CPU selection logic where the subsystem assumes all selected CPUs are valid for operation without proper validation against current online status.
The proposed fix involves implementing cpumask_any_and_distribute() to properly mask the __pod_cpumask with the cpu_online_mask, ensuring that only online CPUs are selected for wake operations. This approach aligns with established best practices for kernel development and addresses the immediate concern of selecting invalid CPUs. However, the analysis acknowledges that this solution does not fully resolve the underlying race condition, as CPUs can still transition offline between the time of target CPU selection and the actual wake call. The vulnerability analysis references CWE-125 as the underlying weakness, which represents an out-of-bounds read condition that occurs when a pointer is dereferenced without proper validation of the target's accessibility. The fix demonstrates adherence to the principle of least privilege and proper resource validation, ensuring that kernel subsystems only operate on valid system resources.
Mitigation strategies should include immediate deployment of the patched kernel version that implements the corrected CPU selection logic, along with monitoring for system stability during CPU online/offline operations. System administrators should also implement proper kernel version management policies to ensure all systems receive timely security updates. The fix addresses the specific ATT&CK technique T1489 which involves system network configuration modification, though in this case it represents a kernel-level configuration error that could potentially be exploited to cause system instability or denial of service conditions. Organizations should also consider implementing additional monitoring for kernel oops messages and system boot failures that may indicate similar race condition vulnerabilities in other kernel subsystems.