CVE-2026-93220: sched_ext: Keep kick_sync waiting on the rq's own CPU
In the Linux kernel, the following vulnerability has been resolved:
schedext: Keep kicksync waiting on the rq's own CPU
kicksyncwaitbalcb() assumes it runs on the rq's CPU from the schedule() tail: the snapshots it compares against live in that CPU's percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled.
However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target.
Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq's next wait picks up the stale cpustosync bits.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The affected path involves sched_ext kick_sync waiting, a queued balance callback, and the runqueue lock being dropped before that callback runs. A scheduler class change path or the scx task iterator can then flush the pending callback on a CPU other than the runqueue's own CPU.
What is the practical impact if the callback runs on a foreign CPU?
It can compare per-CPU snapshots belonging to an unrelated CPU. If the CPU executing the callback is itself a wait target, the busy-wait can deadlock.
Is there a mitigation described for systems that cannot immediately apply the fix?
No operational workaround is provided in the available data. The described resolution is to bail out when the callback is running on a foreign CPU while preserving the wait state for the runqueue's next wait.