CVE-2026-89520

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Make core-sched flips wait for in-flight selections<br /> <br /> Core scheduling&amp;#39;s pick_next_task() operates on all sibling rqs under one<br /> acquisition of the shared core-wide lock. A -&gt;pick_task() that releases the<br /> rq lock leaves every sibling __lock momentarily free, letting<br /> __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under<br /> it. The selection resumes on the split locks, touching sibling state it no<br /> longer protects, and __schedule() finally releases a lock that was never<br /> taken while leaking the one that was.<br /> <br /> Count in-flight core-wide selections in the leader&amp;#39;s rq-&gt;core_pick_in_flight<br /> and make __sched_core_flip() wait for the count to drain. The count only<br /> changes under the shared lock, which the flip holds while sampling, so no<br /> other ordering is needed. The wait can repeat while selections overlap, but<br /> the flip backs off between samples and flips are rare cookie-lifetime<br /> events.<br /> <br /> sched_core_cpu_deactivate() moves the count to the new leader - a stale copy<br /> left behind would bias it forever if that CPU later returns as its own<br /> leader.