CVE-2026-43326 in Linux
Summary
by MITRE • 05/08/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback
SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using smp_cond_load_acquire() until the target CPU's kick_sync advances. Because the irq_work runs in hardirq context, the waiting CPU cannot reschedule and its own kick_sync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.
Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to force the CPU through do_pick_task_scx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the sched_core_balance() pattern, so the CPU can process IPIs while waiting. The local CPU's kick_sync is advanced on entry to do_pick_task_scx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability in question affects the Linux kernel's scheduler extension subsystem, specifically within the SCX_KICK_WAIT mechanism that governs how tasks are migrated between CPUs in the scheduling system. This issue manifests as a deadlock condition that can bring entire systems to a halt when multiple CPUs become trapped in a cyclic waiting pattern. The vulnerability stems from a fundamental flaw in how the kernel handles inter-processor interrupt (IPI) processing within the scheduler's busy-waiting logic, creating a scenario where CPUs cannot make forward progress due to their own scheduling constraints.
The technical flaw exists in the kick_cpus_irq_workfn() function where smp_cond_load_acquire() is used to busy-wait for the target CPU's kick_sync to advance. This busy-waiting occurs within hardirq context, which prevents the waiting CPU from being scheduled to run on the CPU it is waiting for. The hardirq context execution environment disables rescheduling, creating a circular dependency where each CPU in the wait cycle cannot make progress because the CPU it's waiting for cannot advance its own kick_sync due to being blocked by the same mechanism. This condition is particularly insidious because it can affect multiple CPUs simultaneously, creating a system-wide deadlock that requires manual intervention to resolve.
The operational impact of this vulnerability is severe as it can cause complete system hangs, particularly in multi-core environments where task migration is frequent. Systems running with high scheduling pressure or complex workload patterns are most susceptible to this deadlock condition, as the probability of forming wait cycles increases with system complexity. The vulnerability affects the scheduler extension framework's ability to properly balance tasks across CPUs, leading to potential service disruptions, unresponsiveness, and complete system lockups that require rebooting to recover. This type of deadlock represents a critical failure in the kernel's fundamental scheduling infrastructure, potentially affecting all applications and services running on affected systems.
The mitigation strategy involves replacing the problematic busy-waiting mechanism with a more appropriate scheduling approach that allows the CPU to be rescheduled during the wait period. The fix implements resched_curr() to force the CPU through do_pick_task_scx(), which then queues a balance callback that follows the sched_core_balance() pattern. This approach allows the CPU to drop the run queue lock and enable IRQs, creating an execution environment where IPIs can be processed while waiting. The local CPU's kick_sync is advanced upon entry to do_pick_task_scx() and continuously during the wait period, ensuring that any CPU that begins waiting for another sees the advancement and cannot form cyclic dependencies. This solution addresses the root cause by breaking the hardirq context constraint that was preventing proper scheduling and rescheduling of the affected CPUs.
This vulnerability aligns with CWE-367, which addresses Time-of-Check to Time-of-Use (TOCTOU) flaws and race conditions, specifically manifesting as a deadlock condition. From an ATT&CK perspective, this represents a system-level denial of service attack vector that could be exploited to cause complete system unresponsiveness, falling under the T1499.004 technique for Network Denial of Service. The fix demonstrates proper adherence to kernel scheduling best practices by ensuring that high-priority scheduling operations do not block themselves through improper use of busy-waiting mechanisms, following established patterns like sched_core_balance() that have been proven effective in similar scenarios. The solution maintains the essential functionality of the scheduler while eliminating the deadlock condition through proper context switching and scheduling protocol adherence.