Look up another CVE · open CVE-2026-89520 in the interactive tracker
CVE-2026-89520
sched/core: Make core-sched flips wait for in-flight selections
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem kernel/sched. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89520 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/sched/core.c
kernel/sched/sched.h
- What this is
- SCHEDULERMAINTAINERS section matched on kernel/sched/ · linux-kernel@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel/sched
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.14 | 6.12.112 | 3e2511bffa93 |
| 5.14 | 6.18.51 | 9d69422ddaa1 |
| 5.14 | 7.2.4 | 23eda24f325a |
| 5.14 | 7.3 | f3629c63a4af |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The race is in pick_next_task() and __sched_core_flip() in kernel/sched/core.c, reached locally via prctl(PR_SCHED_CORE) cookie create/drop and ordinary schedule() on SMT siblings; there is no network or adjacent-packet path.
- AC:LAttack complexity, low
- The attacker enables core scheduling with PR_SCHED_CORE_CREATE, then drops the last cookie to queue __sched_core_flip(false) while forcing SMT-sibling scheduling so a lock-dropping pick_task() (CFS newidle or sched_ext) releases the shared rq lock; both sides of the race are attacker-controlled and retryable.
- PR:LPrivileges required, low
- sched_core_share_pid() only requires ptrace_may_access(PTRACE_MODE_READ_REALCREDS) on the target, which an unprivileged process always has for itself, so prctl(PR_SCHED_CORE) needs no capability or init-namespace root.
- UI:NUser interaction, none
- No victim action such as mounting a filesystem or opening a file is required; the attacker enables core scheduling on their own tasks and races cookie teardown against their own threads' scheduling.
- S:UScope, unchanged
- Unprotected sibling runqueue accesses and unlocking the rebound rq lock corrupt host kernel scheduler state inside a single security authority; this is not a guest-to-host, IOMMU, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- After __sched_core_flip(false) rebinds rq_lockp() mid-selection, pick_next_task() keeps reading sibling rq and task_struct fields without the core-wide lock, so concurrent scheduler-structure corruption can be turned into a kernel memory-disclosure primitive.
- I:HIntegrity impact, high
- The same unlocked sibling walk can place one task_struct on two CPUs, and __schedule() then unlocks a lock it never took while leaking the shared core lock, yielding write and control-flow hijack primitives against scheduler state.
- A:HAvailability impact, high
- Unlocking an unheld lock, leaking the shared core lock, and racing sibling runqueue mutation cause kernel oops, lockdep panics, deadlocks, and hangs.