CVE-2026-99255 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: don't hide a link from cancellations
A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed.
When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found:
io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked
It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either.
NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later
With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM):
io_uring_cancel_generic do_exit
Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req().
Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel vulnerability identified involves a race condition within the io_uring subsystem, specifically affecting how linked asynchronous I/O requests are handled during task or process termination. The core issue arises from a timing gap where an exiting thread cancels its tracked requests and waits for them to complete, but fails to locate a specific linked request due to it being in an intermediate state of transition between workers. When io_wq finishes processing a request that has a link attached, there is a brief window during which the subsequent request in the chain cannot be found by cancellation logic. This occurs because the next request is neither pending nor currently assigned as work for any worker, and it has not yet been placed on the list where cancellations typically search. Consequently, if an exiting task's cancellation pass coincides with this specific interval, io_uring_cancel_generic() finds nothing to cancel and proceeds to sleep, expecting to be woken up when requests are completed or freed.
The operational impact of this flaw is significant, leading to potential hangs in the system. Specifically, bounded work items can continue execution even after an exit signal has been issued because the IO_WQ_BIT_EXIT flag does not prevent their processing during this window. If such a request parks without being properly completed or freed, no wake-up event occurs for the sleeping task. In scenarios involving process exits, this results in the inability to kill the process effectively, causing it to hang indefinitely. Empirical testing demonstrates that with four linked requests per round across five to eight out of ten thousand rounds on multi-core systems using KVM virtualization, hangs occur consistently after up to sixty-three microseconds following thread or process exit signals involving FUTEX_WAIT operations combined with asynchronous I/O links.
This vulnerability is categorized under CWE-362, which describes concurrent execution issues leading to race conditions where shared resources are accessed without proper synchronization. From a threat modeling perspective aligned with the MITRE ATT&CK framework, this behavior relates to Defense Evasion techniques, particularly those involving resource hijacking or persistence through hung processes that prevent normal system cleanup and termination procedures. The flaw exploits the asynchronous nature of io_uring work queues where state transitions are not atomic relative to cancellation checks, allowing a request to slip into an untracked state during the critical period between freeing one work item and assigning the next linked item as current worker activity.
The resolution involves modifying the lifecycle management of these requests by splitting the io_wq_free_work() function into two distinct phases. The fix ensures that requests are freed only after they become either the current work of a worker or pending status, thereby guaranteeing that any wake-up events triggered during this transition can be correctly identified and processed by cancellation logic. This adjustment closes the race window where links were previously hidden from cancellations, ensuring that exiting tasks always find their associated requests to cancel properly. By aligning the freeing mechanism with the visibility requirements of io_uring_cancel_generic(), the kernel prevents scenarios where linked I/O operations escape termination signals, restoring reliable process exit behavior and preventing system hangs caused by orphaned asynchronous work items.