GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sched_ext: DSQ consume and move paths operate on a task still being dispatched

CVSS 7.8CVE-2026-99269Kernel, userspace & hypervisorcurated

Impact

A task can sit on a non-local dispatch queue while the CPU that dispatched it is still inside ops.dequeue() with SCX_OPSS_DISPATCHING set. The consume and move paths did not wait for that dispatch to finish, so they manipulate the task concurrently with the dispatcher, including in scx_resolve_local_dsq() which may update p->scx.flags. The fix adds scx_wait_dispatching() calls before those operations. Reachable only where a BPF scheduler is actually loaded through sched_ext - clusters using a custom scheduler for GPU job placement or latency isolation. On a stock CONFIG_SCHED_CLASS_EXT kernel with no BPF scheduler attached, the code path is not exercised, so most fleets are unaffected in practice; loading a sched_ext scheduler already requires privilege, which limits this to a stability and correctness fix for those who do.

Who can reach it

Local, and only on a node running a loaded sched_ext BPF scheduler; triggering the race requires workload timing against a dispatching CPU rather than any special permission. Attaching a sched_ext scheduler in the first place needs CAP_BPF/CAP_SYS_ADMIN.

What to do

Take the two stable kernel commits in the advisory, or a distro kernel that includes them, and reboot the affected nodes - a kernel scheduler core change cannot be hot-patched here. Clusters that do not load a sched_ext BPF scheduler can treat this as routine and fold it into the next scheduled kernel roll.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.