CVE-2026-68094 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Preserve rq tracking across local DSQ dispatch
dispatch_to_local_dsq() can run from scx_bpf_dsq_move_to_local() while ops.dispatch() has recorded the current rq. Moving a task to a local DSQ may switch to the source or destination rq before synchronously invoking ops.dequeue() through the following path:
SCX_CALL_OP(dispatch, rq) ops.dispatch() scx_bpf_dsq_move_to_local() scx_flush_dispatch_buf() finish_dispatch() dispatch_to_local_dsq() scx_dispatch_enqueue() local_dsq_post_enq() call_task_dequeue() SCX_CALL_OP_TASK(dequeue, locked_rq, ...)
The nested callback saves the recorded rq and restores it on return. If the rq tracking does not follow the lock switch, update_locked_rq() can trigger the following lockdep assertion while restoring an rq which is no longer held:
WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170 Call Trace: scx_dispatch_enqueue+0x2b0/0x460 dispatch_to_local_dsq+0x138/0x230 scx_flush_dispatch_buf+0x1af/0x220 scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0 bpf__sched_ext_ops_dispatch+0x4b/0xa7 do_pick_task_scx+0x3b6/0x910 __pick_next_task+0x105/0x1f0 __schedule+0x3e7/0x1980
Introduce switch_rq_lock() to update the tracking state together with each rq lock handoff. Use it in dispatch_to_local_dsq(), move_remote_task_to_local_dsq() and the in-balance paths of scx_dsq_move(), ensuring that scx_locked_rq() consistently refers to the rq whose lock is actually held throughout the lock dance.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described represents a critical race condition in the Linux kernel's scheduler extension subsystem, specifically within the sched_ext framework that enables BPF-based scheduling policies. This issue stems from improper tracking of runqueue (rq) context during asynchronous task dispatch operations where the scheduler must maintain consistent locking state across multiple runqueue transitions. The flaw manifests when tasks are moved between local dispatch scheduling queues (DSQs), creating a scenario where the scheduler's internal tracking mechanism becomes out of sync with actual lock ownership, leading to potential system instability and incorrect scheduling behavior.
The technical root cause involves the interaction between multiple callback mechanisms within the scheduler's dispatch pipeline. When scx_bpf_dsq_move_to_local() invokes dispatch_to_local_dsq(), it operates under the assumption that the runqueue tracking remains consistent despite the lock switching that occurs during the operation. However, the nested callback structure causes a situation where the recorded rq context is saved and restored, but this restoration can occur after a lock handoff has already taken place. This mismatch triggers a lockdep assertion in the scheduler's internal consistency checking mechanism, specifically at the call_task_dequeue function where update_locked_rq() attempts to restore a runqueue reference that no longer corresponds to the currently held lock.
The operational impact of this vulnerability extends beyond simple system stability concerns into potential security implications within kernel space operations. When lockdep assertions trigger, they indicate that the scheduler's internal state management has become corrupted, which could allow for unpredictable task scheduling behavior or even privilege escalation opportunities through carefully crafted BPF programs that exploit the race condition. The vulnerability affects any system running with sched_ext enabled and using BPF scheduling policies that perform task movement between DSQs, making it particularly concerning for high-performance computing environments and containerized systems where custom scheduling policies are commonly deployed.
The mitigation strategy implemented involves introducing a new function called switch_rq_lock() that synchronizes runqueue tracking state with each lock handoff operation. This solution directly addresses the core problem by ensuring that scx_locked_rq() always refers to the actual runqueue whose lock is currently held, regardless of the complex locking dance that occurs during task dispatch operations. The fix properly handles three key code paths: dispatch_to_local_dsq(), move_remote_task_to_local_dsq(), and the in-balance paths of scx_dsq_move(). This approach aligns with established security patterns for managing kernel lock states and prevents the type of context confusion that leads to lockdep violations. The solution follows ATT&CK framework concept T1068 by addressing privilege escalation pathways through kernel memory corruption, while also mapping to CWE-367 which deals with time-of-check to time-of-use vulnerabilities in kernel synchronization primitives. The implementation ensures that all runqueue state transitions maintain proper consistency, thereby preventing the assertion failures that could lead to system crashes or more serious security implications in properly crafted exploit scenarios.