CVE-2026-90432 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Abort directly from the hardlockup handler
scx_hardlockup() defers the abort to an irq_work because exit claiming used to take scx_sched_lock and couldn't run from NMI. The deferral is now unnecessary - claiming is NMI-safe and asserting ->aborting is exactly what breaks the live-locks that hard-lock CPUs. Call handle_lockup() directly and drop the irq_work. This also makes the self-detected case recoverable: the perf watchdog fires on the hard-locked CPU itself, where a queued irq_work never runs with IRQs off.
Also fix the return value: %true used to be returned whenever sched_ext was loaded, suppressing the kernel's hardlockup report even when the abort was refused. Return %true only when this call initiated the abort.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel scheduler extension subsystem contains a critical flaw in its handling of hard lockups that can prevent proper system recovery and obscure diagnostic information during severe scheduling stalls. The vulnerability centers on the scx_hardlockup function, which is responsible for detecting when a CPU has been stuck in a non-interruptible state for an extended period. Previously, this function attempted to defer the abort operation using irq_work because the underlying exit claiming mechanism relied on acquiring the scx_sched_lock. Since spinlocks cannot be safely acquired from Non-Maskable Interrupt contexts, such as those generated by hardware watchdogs or performance monitoring units, direct execution was deemed unsafe and potentially dangerous for system stability. This architectural decision introduced a layer of indirection that proved problematic under specific failure conditions where immediate action is required to break the deadlock.
The operational impact of this design flaw becomes apparent when considering how hard lockups are detected in modern Linux systems. The perf watchdog typically fires on the CPU that has become unresponsive, triggering an interrupt handler while interrupts may be disabled or restricted depending on the context. In such scenarios, queuing irq_work for later execution is ineffective because the deferred work item relies on normal scheduling paths to run, which are unavailable when the system is hard-locked. Consequently, the abort mechanism fails to execute, leaving the CPU stuck in its locked state indefinitely. This not only prevents self-recovery but also suppresses critical kernel diagnostic reports if the function incorrectly returns a success status even when the abort was refused or never attempted due to the deferral logic.
The resolution involves removing the unnecessary deferral layer by ensuring that exit claiming is NMI-safe and directly calling handle_lockup from within the hardlockup handler. By asserting an ->aborting flag, the system can effectively break live-locks without requiring complex lock acquisition sequences that are incompatible with interrupt contexts. This change allows the kernel to respond immediately to watchdog timeouts on the affected CPU itself, enabling self-detected cases to recover properly rather than hanging indefinitely. The fix also corrects the return value logic so that true is only returned when an abort was actually initiated by this call, ensuring that standard hardlockup reporting mechanisms are not suppressed incorrectly and providing accurate feedback for debugging tools like kdump or panic handlers.
From a security and reliability perspective, this vulnerability aligns with CWE-834 regarding excessive locking contention leading to denial of service through resource exhaustion or deadlock. The improper handling of interrupt contexts represents a classic concurrency error where assumptions about lock safety are violated under edge cases involving NMI execution paths. In terms of the MITRE ATT&CK framework, while not an exploit vector for unauthorized access, this flaw impacts system availability and integrity by preventing automated recovery mechanisms from functioning as designed during critical failures. It falls under techniques related to resource hijacking or denial of service via kernel-level instability rather than malicious exploitation.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that updates the sched_ext subsystem to handle hard lockups directly without deferral. System administrators should ensure their kernels are updated to versions containing this fix, particularly those running with scheduler extensions enabled for custom scheduling policies. Additionally, monitoring tools should be configured to detect and report hardlockup events accurately, as the corrected return value ensures that such incidents are no longer silently suppressed by the sched_ext module. Regular kernel updates remain the most effective defense against these types of internal logic errors that compromise system resilience during high-load or fault conditions.