CVE-2026-89520: Linux Kernel Race Condition Vulnerability

CVE-2026-89520 Overview

CVE-2026-89520 is a race condition in the Linux kernel's core scheduler affecting the pick_next_task() selection path. The flaw resides in sched/core where core scheduling operates across sibling run-queues under a shared core-wide lock. A ->pick_task() implementation that releases the run-queue lock exposes a window where __sched_core_flip(false) can complete mid-selection, rebinding rq_lockp() beneath the in-flight selector. The resumed selection touches sibling state it no longer protects, and __schedule() releases a lock that was never acquired while leaking the one that was. The defect enables local memory corruption and scheduler state inconsistency on kernels with core scheduling enabled.

Critical Impact
A local attacker with the ability to trigger core-scheduling cookie lifetime events can corrupt scheduler run-queue state, potentially causing kernel instability, information disclosure, or privilege escalation on affected Linux systems.

Affected Products

Linux kernel builds with CONFIG_SCHED_CORE enabled
Distributions shipping vulnerable stable kernels prior to the fix commits
Systems using core scheduling for SMT-aware workload isolation

Discovery Timeline

2026-09-11 - CVE-2026-89520 published to NVD
2026-09-13 - Last updated in NVD database

Technical Details for CVE-2026-89520

Vulnerability Analysis

The vulnerability is a race condition ([TOCTOU]-class) in the Linux core scheduler's pick path. Core scheduling coordinates task selection across SMT siblings on a physical core, requiring all sibling run-queues to be evaluated atomically under one shared lock. The pick_next_task() routine relies on rq_lockp() returning a stable lock pointer for the duration of the selection.

When a ->pick_task() callback drops the run-queue lock momentarily, each sibling __lock becomes free. During this window, __sched_core_flip(false) can execute, transitioning the core out of cookie-enforced mode and rebinding rq_lockp() from the shared core-wide lock to per-CPU locks. The selection then resumes operating on split locks while continuing to mutate sibling run-queue state it no longer serializes access to. On exit, __schedule() releases a lock that was never taken and leaks the one it originally acquired.

The fix introduces a core_pick_in_flight counter in the leader's run-queue. __sched_core_flip() samples the counter under the shared lock and waits for it to drain before completing the flip, ensuring in-flight selections finish before the lock topology changes.

Root Cause

The root cause is missing synchronization between core-scheduling state transitions and in-flight task selection. The flip operation assumed pick_next_task() held the shared lock continuously, but ->pick_task() implementations that temporarily release the lock violate that assumption. The scheduler had no mechanism to detect or wait for concurrent selections spanning a lock-topology change.

Attack Vector

Exploitation requires local access with permission to schedule tasks that trigger core-scheduling cookie transitions. An attacker constructs workloads that repeatedly cause __sched_core_flip(false) to fire while a sibling CPU is executing pick_next_task() with a ->pick_task() that releases the run-queue lock. Winning the race corrupts scheduler bookkeeping, unbalances lock ownership, and can lead to kernel memory corruption or a crash. Because the primitive touches sibling run-queue state under an incorrect lock, memory disclosure and further exploitation paths are plausible.

Refer to the upstream stable commits for the precise fix: commit 23eda24f, commit 9d69422d, and commit f3629c63.

Detection Methods for CVE-2026-89520

Indicators of Compromise

Unexplained kernel oopses or WARN_ON splats originating from kernel/sched/core.c referencing pick_next_task, __sched_core_flip, or rq_lockp.
Lockdep reports flagging inconsistent lock acquisition or release around scheduler paths on kernels with CONFIG_SCHED_CORE=y.
Sporadic soft lockups or scheduler stalls on SMT-enabled hosts running workloads that toggle core-scheduling cookies.

Detection Strategies

Query installed kernel versions across the fleet and compare against fixed stable-tree commits from git.kernel.org.
Enable kernel lockdep and KASAN in test environments to surface the race during workload validation.
Audit process creation of workloads that invoke prctl(PR_SCHED_CORE, ...) to set or clear core-scheduling cookies.

Monitoring Recommendations

Collect dmesg and journald kernel logs into a central analytics store and alert on scheduler-related warnings.
Track unexpected kernel panics on hosts with CONFIG_SCHED_CORE enabled, correlated with workloads using core-sched cookies.
Monitor for local privilege escalation indicators such as unexpected UID transitions or new SUID binaries following kernel instability events.

How to Mitigate CVE-2026-89520

Immediate Actions Required

Apply the upstream stable kernel updates that include the core_pick_in_flight counter fix and reboot affected hosts.
Inventory hosts built with CONFIG_SCHED_CORE=y and prioritize patching multi-tenant and SMT-heavy systems first.
Restrict local shell access on unpatched hosts and audit users with the ability to set core-scheduling cookies.

Patch Information

The fix is upstream across three stable-tree commits: 23eda24f325a, 9d69422ddaa1, and f3629c63a4af. Consume the fix through your distribution's kernel security update channel, or rebuild from a patched stable branch. Verify the running kernel with uname -r after reboot.

Workarounds

Disable core scheduling by booting with sched_core=off or building kernels without CONFIG_SCHED_CORE where the feature is not required.
Disable SMT (nosmt kernel parameter) on affected hosts if core scheduling was enabled specifically for SMT isolation.
Constrain untrusted local workloads with seccomp policies that block prctl(PR_SCHED_CORE, ...) invocations.

bash

# Verify kernel version and core-scheduling configuration
uname -r
grep CONFIG_SCHED_CORE /boot/config-$(uname -r)

# Temporary mitigation: disable core scheduling at boot
# Edit /etc/default/grub and append to GRUB_CMDLINE_LINUX:
#   sched_core=off
sudo update-grub && sudo reboot