CVE-2026-89517: Linux Kernel Race Condition Vulnerability

CVE-2026-89517 Overview

CVE-2026-89517 is a Linux kernel vulnerability in the sched_ext extensible scheduler class affecting core scheduling on Simultaneous Multi-Threading (SMT) systems. The flaw corrupts the rq->core_pick state when sched_ext dispatch releases the core-wide runqueue lock during pick_next_task(). Concurrent selections on the same core interleave through the dropped lock and overwrite each other's picks. The result is a NULL pointer dereference or a dequeued task left running, which deadlocks the next wakeup. A cookied ping-pong workload on an SMT machine reproduces hard kernel hangs within seconds.

Critical Impact
The vulnerability causes NULL pointer dereferences and kernel deadlocks, leading to complete system hangs on SMT hardware running sched_ext with core scheduling enabled.

Affected Products

Linux kernel builds with CONFIG_SCHED_CLASS_EXT enabled
Systems running core scheduling on SMT-capable CPUs
Kernel versions containing commit 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()")

Discovery Timeline

2026-09-11 - CVE-2026-89517 published to the National Vulnerability Database
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89517

Vulnerability Analysis

Core scheduling's pick_next_task() selects tasks for every SMT sibling of a core in a single pass while holding the shared core-wide runqueue lock. The selection state remains consistent only while that lock is held continuously. Historically, ->pick_task() could not release the lock for this reason.

Commit 4c95380701f5 changed this contract by folding balance_scx() into pick_task_scx(). The sched_ext dispatch path now runs from inside the pick and can drop the runqueue lock. When two selections on the same core interleave through a dropped lock, they corrupt one another's state. One selection clears the other's rq->core_pick, producing a NULL dereference. Alternatively, it invalidates a keep-the-previous-task decision, leaving a dequeued task running and deadlocking the next wakeup.

Root Cause

The root cause is a race condition [CWE-362] between concurrent core-wide scheduling decisions when the sched_ext dispatch path releases the core-wide runqueue lock mid-selection. The original invariant that pick_next_task() runs atomically under a continuously held lock is violated, so cross-sibling selection state is no longer consistent when committed.

Attack Vector

Exploitation requires a local workload that repeatedly triggers sched_ext dispatch and core scheduling decisions on SMT siblings. A cookied ping-pong load exercising core scheduling makes the interleavings frequent. The observed outcome is a denial-of-service through kernel hangs. There is no evidence of remote exploitation or privilege escalation vectors published with this CVE.

See the upstream fix commits for technical details: Kernel Git Commit Details and Kernel Git Commit Update.

Detection Methods for CVE-2026-89517

Indicators of Compromise

Kernel panics or NULL pointer dereferences with stack traces referencing pick_next_task, pick_task_scx, or rq->core_pick.
Hard system hangs on SMT hosts running sched_ext policies with core scheduling enabled.
WARN_ON output from put_prev_task_scx() indicating a runnable task was left behind.

Detection Strategies

Inventory Linux hosts with CONFIG_SCHED_CLASS_EXT=y and identify any active sched_ext scheduler using scx_show_state or bpftool prog list.
Correlate kernel crash telemetry against affected kernel versions to distinguish this issue from unrelated scheduler faults.
Monitor for repeated soft lockup or RCU stall warnings tied to specific CPU cores under scheduler load.

Monitoring Recommendations

Ship kmsg and dmesg output to a central log store and alert on scheduler-related oops signatures.
Track uptime regressions on SMT hosts running non-default schedulers such as scx_rusty, scx_layered, or scx_lavd.
Baseline scheduler-class configuration across the fleet and alert on unauthorized changes to sched_ext enablement.

How to Mitigate CVE-2026-89517

Immediate Actions Required

Apply the upstream kernel patches referenced in the fix commits as soon as vendor-built kernels are available.
On affected hosts that cannot be patched immediately, unload or disable any active sched_ext scheduler and revert to the default CFS/EEVDF class.
Prioritize remediation on SMT hardware where core scheduling is enabled, since these systems reproduce the hang most reliably.

Patch Information

The fix makes pick_task_scx() return RETRY_TASK whenever dispatch released the runqueue lock, so a selection only commits picks made under a continuously held lock. A per-rq lock_drop_seq counter tracks releases, retries are bounded, and idle CPUs do not loop. Balance callbacks are executed directly when dispatching for another rq, and the put_prev_task_scx() warning is gated to the non-core path. Apply the changes in commits cdafb68155be and d954004205c1 from the stable kernel tree.

Workarounds

Disable core scheduling on affected hosts by not assigning core-scheduling cookies to workloads.
Stop the sched_ext scheduler process so the kernel falls back to the default scheduler class.
Disable SMT via kernel boot parameter nosmt where operationally acceptable, which removes the sibling interleaving required to trigger the corruption.

bash

# Stop any running sched_ext scheduler and verify fallback to default class
sudo pkill -f scx_ || true
cat /sys/kernel/sched_ext/state

# Optional: disable SMT at runtime as a defense-in-depth workaround
echo off | sudo tee /sys/devices/system/cpu/smt/control