CVE-2026-90432: sched_ext: Abort directly from the hardlockup handler
In the Linux kernel, the following vulnerability has been resolved:
schedext: Abort directly from the hardlockup handler
scxhardlockup() defers the abort to an irqwork because exit claiming used to take scxschedlock 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 handlelockup() directly and drop the irqwork. This also makes the self-detected case recoverable: the perf watchdog fires on the hard-locked CPU itself, where a queued irqwork never runs with IRQs off.
Also fix the return value: %true used to be returned whenever schedext was loaded, suppressing the kernel's hardlockup report even when the abort was refused. Return %true only when this call initiated the abort.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel with sched_ext loaded are relevant. The issue concerns hard-lockup handling in sched_ext, including cases where the perf watchdog detects the lockup on the affected CPU itself.
What is the operational impact during a hard lockup?
The prior deferred abort could fail to run when the hard-locked CPU had interrupts disabled, preventing recovery in the self-detected case. It could also suppress the kernel hardlockup report whenever sched_ext was loaded, even if an abort was refused.
How does the resolved behavior change hard-lockup handling?
The abort is initiated directly from the hardlockup handler rather than being queued through irq_work. The handler now reports success only when it actually initiated the abort.