Cloudanix VulnDB

CVE-2026-90432

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug could stop the system from recovering properly when a processor freezes, increasing the chance of crashes or freezes.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability allowed deferral of sched_ext abort via irq_work from the hardlockup NMI handler instead of direct call to handle_lockup, preventing proper live-lock breaking and causing incorrect return values that suppressed kernel hardlockup reports even when abort was refused.

Why it matters to the business

Systems using sched_ext scheduling could experience unrecoverable CPU lockups or missed detection of hangs, leading to unplanned downtime and reduced reliability in Linux environments.

How an attack unfolds

An attacker triggers conditions that cause hard CPU lockups in a sched_ext-enabled kernel; the deferred abort mechanism fails to execute under IRQs-off, allowing the lockup to persist without recovery or logging.

How to fix it

Update to a Linux kernel version containing the sched_ext hardlockup handler fix that calls handle_lockup directly from the NMI context and corrects the return value logic.

How to confirm the fix worked

Confirm kernel source includes direct handle_lockup call from scx_hardlockup without irq_work deferral and verifies return value is true only on successful abort initiation.

Typical attack path

  1. Identify or induce workload that triggers sched_ext hardlockup detection
  2. Exploit NMI context where irq_work deferral cannot run
  3. Prevent abort from breaking live-lock, causing persistent hang

How to detect it

Review kernel logs for hardlockup reports that were incorrectly suppressed or for evidence of persistent IRQs-off states on CPUs using sched_ext; correlate with perf watchdog events.

What your security team should do

  • Prioritize kernel upgrades for systems running sched_ext
  • Monitor for hardlockup events in kernel logs post-update
  • Test sched_ext workloads in staging before production rollout

The record

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.

Affected packages

Ecosystem Package Introduced Fixed