CVE-2026-89521
massRace in Linux kernel core-scheduling pick path breaks task isolation
The Linux kernel's core-scheduling logic in sched/core mishandles the case where a ->pick_task() implementation releases the runqueue (rq) lock, invalidating the selection state that pick_next_task() derived on entry. A local attacker with low privileges can trigger this race so that the single-CPU fast path commits an 'uncookied' task pick on a core that became 'cookied' while the lock was released, and forceidle accounting is skewed by an interleaving selection. On hosts that rely on core scheduling to enforce isolation (for example, to prevent SMT/L1TF/MDS side-channel leakage between containers, VMs, or sandboxed workloads), this can violate the intended security boundary, which is reflected in the CVSS 3.1 score of 7.3 with high confidentiality and availability impact. All systems running a kernel with the vulnerable sched/core code are affected in principle, but the practical security impact is concentrated on multi-tenant or isolation-sensitive deployments that enable core scheduling. No public proof of concept is known, the issue is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.
What to do: Apply your distribution's kernel update as soon as it backports the sched/core fix (which restarts the selection on RETRY_TASK after a lock release) and reboot the host. If you run multi-tenant servers or sandboxes that depend on core scheduling for SMT side-channel isolation, prioritize this patch and review whether untrusted local users share hyperthreaded cores in the meantime. There is no configuration-only mitigation, so verify after upgrading that core-scheduling behavior and forceidle accounting look correct.
| Linux kernel | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: sched/core: Handle pick_task() releasing the rq lock Core scheduling's pick_next_task() breaks when a ->pick_task() implementation can release the rq lock. The selection state derived on entry is only valid while the lock is held continuously. Once a pick can drop the lock, an interleaving selection can invalidate all of it: the single-CPU fast path can commit an uncookied pick although the core went cookied during the release, and forceidle committed by the interleaving selection skews the restarted pass's accounting. Fix it by restarting the whole selection when a pick returns RETRY_TASK after releasing the lock: a single restart point above the state derivation replaces the per-loop restart labels, so a retry picks up state committed by interleaving selections and accounts and resets forceidle like a fresh selection would. need_sync and fi_before latch across retries. Clock validity can't be re-derived - there is no program-ordered way to tell whether the own and core rq clocks are still updated after the lock was released, as other lockers' pin cycles may or may not have invalidated them. When restarting, clear core_clock_updated so that the sibling loop re-updates the core rq, and update the own rq clock if invalidated.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
In the news0 stories
No ingested article mentions this CVE yet.