CVE-2026-64425 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item
commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.
io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun.
Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a race condition within the linux kernel's io_uring implementation, specifically in the io-wq (io workqueue) subsystem that handles asynchronous I/O operations. This issue affects the io_worker_handle_work function which processes linked work items in a sequential chain where each item depends on the completion of its predecessor. The problem manifests when multiple work items are linked together and processed as a unit, creating a scenario where the exit signaling mechanism fails to properly account for concurrent modifications during execution.
The technical flaw stems from an incomplete fix that addresses only part of the race condition. While the original commit 10dc95939817 correctly implemented re-checking of the IO_WQ_BIT_EXIT flag within the outer work loop, it failed to extend this protection to linked work items that form dependent chains. The function snapshots the exit bit once before processing an entire chain of linked work items, which means that if io_wq_exit_start() sets the exit flag after the first item begins execution but before subsequent items complete, those remaining items will continue execution with stale state information.
This vulnerability creates a scenario where linked work items can execute beyond their intended lifecycle, potentially leading to system instability and resource exhaustion. The fix requires moving the exit bit check deeper into the processing logic so that each individual linked item receives its own fresh exit status check rather than relying on a single snapshot for the entire chain. This ensures that if an exit signal is received during processing of a linked chain, all remaining items in that chain will properly terminate and not continue executing.
The operational impact of this vulnerability can be significant in systems handling high volumes of io_uring operations, particularly when dealing with slow devices or complex I/O workloads where linked work chains are common. The described scenario involving syzbot testing demonstrates how this issue becomes more pronounced when creating numerous slow linked work items on devices like msr (model specific registers) that take extended time to process before the ring is closed, resulting in prolonged exit operations and potential resource leaks.
This vulnerability aligns with CWE-362, which describes a race condition where multiple threads or processes access shared resources concurrently without proper synchronization mechanisms. From an ATT&CK perspective, this represents a privilege escalation vector through kernel memory corruption and resource exhaustion attacks that could potentially be leveraged by malicious actors to destabilize system operations. The fix addresses the fundamental issue of insufficient atomicity in the exit signaling mechanism for linked work item processing within the kernel's asynchronous I/O subsystem.
The mitigation approach requires updating the io_worker_handle_work function to implement per-item exit bit checking rather than chain-wide snapshotting, ensuring that each linked work item independently evaluates whether the system is in exit state before proceeding with execution. This approach follows established kernel security patterns for handling concurrent access to shared state variables and prevents the propagation of stale state information through dependent work chains.