Live › vulnerability › CVE-2026-98864
Go to dashboardIn the Linux kernel's sched_ext scheduler, a task can be reenqueued while its dispatch is still in progress, and the dispatcher's final state write then overwrites the queued state. The sources describe a scheduling correctness bug where later dispatches of the task are dropped; they do not describe code execution or data access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel that includes the sched_ext scheduler and the commit ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics"). The sources do not name affected kernel versions or whether sched_ext is enabled by default. unknown
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98864")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.