CVE-2026-89521: sched/core: Handle pick_task() releasing the rq lock
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Handle picktask() releasing the rq lock
Core scheduling's picknexttask() breaks when a ->picktask() 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 RETRYTASK 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.
needsync and fibefore 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 coreclockupdated so that the sibling loop re-updates the core rq, and update the own rq clock if invalidated.
Affected Software
Event History
Frequently Asked Questions
What state is preserved when task selection is retried?
The need_sync and fi_before values remain latched across retries. The restarted selection otherwise re-derives selection state and handles forceidle accounting and reset as a fresh selection.
Why are scheduler clocks cleared rather than re-derived after the lock is released?
The scheduler cannot determine in program order whether the local and core runqueue clocks remained updated while the lock was released. Other lock holders may have invalidated clock validity during their pin cycles.