CVE-2026-89521

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.