CVE-2026-89520

The Linux kernel's core-scheduling subsystem contains a race condition where __sched_core_flip() can rebind runqueue locks while pick_next_task() is mid-selection on SMT siblings, because a ->pick_task() implementation that temporarily drops the rq lock leaves the shared core-wide lock momentarily free. When this happens, the scheduler resumes the selection on the now-split locks, touches sibling runqueue state it no longer protects, and __schedule() ultimately releases a lock it never acquired while leaking the one it did hold, corrupting locking state in the kernel. An attacker with existing local, low-privilege code execution on an affected system can race the core-sched flip (a rare cookie-lifetime or CPU-hotplug event) against task selection to trigger memory corruption, with high impact on confidentiality, integrity, and availability — realistically a kernel privilege escalation or crash (CVSS 7.8). Systems running kernels built with core scheduling (CONFIG_SCHED_CORE) and that exercise core-sched cookies are affected. The flaw is fixed upstream in the kernel's sched/core code, and there is no public proof of concept and no evidence of in-the-wild exploitation.

What to do: Patch to a kernel release or distro package that carries this sched/core fix (track the upstream commit and its stable-branch backports). If patching is delayed, minimize risk by avoiding core-scheduling usage (not creating PR_SCHED_CORE cookies) where feasible and restricting local unprivileged code execution on multi-tenant SMT hosts. Verify whether your kernel is built with CONFIG_SCHED_CORE and whether any workload or hypervisor feature uses core-sched cookies to gauge real exposure.