CVE-2026-98864: Linux kernel · sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task
Affects Linux kernelSource GCVE Database
Not known to be exploited · CVSS 5.7 Medium.
Data as of 28 Oct 2026, 22:29 UTC
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 18 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Ubuntu 24.04 LTSlinux-aws-6.14pkg:deb/ubuntu/linux-aws-6.14?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Ubuntu 24.04 LTSlinux-aws-6.17pkg:deb/ubuntu/linux-aws-6.17?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Ubuntu 24.04 LTSlinux-azure-6.11pkg:deb/ubuntu/linux-azure-6.11?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Ubuntu 24.04 LTSlinux-azure-6.14pkg:deb/ubuntu/linux-azure-6.14?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Ubuntu 24.04 LTSlinux-azure-6.17pkg:deb/ubuntu/linux-azure-6.17?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Ubuntu 24.04 LTSlinux-azure-fde-6.14pkg:deb/ubuntu/linux-azure-fde-6.14?arch=source&distro=nobleOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") moved the final ops_state store in scx_dispatch_enqueue() after the DSQ unlock so that the custody update and ops.dequeue() precede it. A task can thus be found on a DSQ while still SCX_OPSS_DISPATCHING. The dequeue and core-sched pick paths wait for the state to clear in ops_dequeue() but the reenqueue paths don't. A reenqueue in that window runs ops.enqueue() and sets SCX_OPSS_QUEUED before the dispatch has completed. The dispatcher's final store then overwrites it with SCX_OPSS_NONE and finish_dispatch() drops every later dispatch of the task. Wait for SCX_OPSS_DISPATCHING to clear before dequeueing a task for reenqueue, the same way ops_dequeue() does.