CVE-2026-99228 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: don't lose the signal that ends work
When a thread exits, only its tracked requests are cancelled. Then its io-wq is torn down. io_wq_exit_workers() signals every worker, to get it out of an interruptible sleep, and waits for all of them to exit. Before they do, they go through the work that is left. Unbounded work is cancelled. Bounded work is run, as it is expected to end by itself.
Not all of it does. An open has no file yet, so it counts as bounded, and the open of a FIFO waits for the other end. That is what the signal is for. But the workers are signalled once, and a worker that hasn't started the work by then loses the signal:
io_wq_exit_workers() io_worker_handle_work() io_wq_worker_wake() set TIF_NOTIFY_SIGNAL io_assign_current_work() io_run_task_work() clear TIF_NOTIFY_SIGNAL io_wq_submit_work() fifo_open() wait_for_partner() wait_for_completion_timeout()
The thread never gets out of do_exit():
IORING_OP_OPENAT of a FIFO without a writer, IOSQE_ASYNC exit of the thread that has submitted it
hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is killed.
Set TIF_NOTIFY_SIGNAL for bounded work that is started with IO_WQ_BIT_EXIT set. The bit is set before the workers are signalled, and it is tested after the flag has been cleared, with clear_notify_signal() providing the barrier. So either the flag stays, or the bit is seen.
Work that is started while the io-wq exits is treated like work that is being run at that time: it isn't interrupted unless it waits interruptibly.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel's io_uring subsystem contains a race condition in its worker thread management logic, specifically within the io_wq_exit_workers function, which can lead to process hangs during system shutdown or thread termination scenarios. This vulnerability arises from an improper handling of signal delivery for bounded work items that are initiated as the worker pool is being torn down. When a user-space thread exits, it cancels its tracked requests and triggers the teardown of its associated io-wq instance. The kernel then signals all active workers to wake them from interruptible sleep states so they can exit cleanly. However, there exists a critical timing window where a worker that has not yet begun processing a specific work item may miss this signal entirely if it starts the work after the signal was broadcast but before it had processed any pending tasks.
The technical flaw centers on bounded I/O operations, such as opening a FIFO (named pipe) without an existing writer. Unlike unbounded work which is forcibly cancelled during exit sequences to prevent indefinite blocking, bounded work is expected to complete naturally and thus is not interrupted by default. In the case of a FIFO open operation that waits for a partner process, the worker thread enters an interruptible sleep state via wait_for_completion_timeout while waiting for the other end of the pipe to connect. Because the TIF_NOTIFY_SIGNAL flag was cleared before this specific work item began execution in certain race conditions, the subsequent signal sent by io_wq_exit_workers fails to wake the sleeping worker. Consequently, the thread remains stuck in do_exit(), unable to proceed with cleanup and termination procedures.
This defect results in a denial of service condition where processes fail to terminate gracefully when they have submitted asynchronous openat operations on FIFOs that lack an immediate writer. Empirical testing indicates this hang occurs in more than ninety percent of attempts under specific conditions involving four CPUs within KVM environments, requiring manual intervention such as killing the process with SIGKILL to resolve the deadlock. The issue effectively prevents proper resource cleanup and can lead to system instability or application hangs if not addressed by external forceful termination methods.
To mitigate this vulnerability, kernel developers implemented a fix that ensures bounded work items started during the exit sequence retain the TIF_NOTIFY_SIGNAL flag until they have safely cleared it after execution begins. This is achieved by checking for the IO_WQ_BIT_EXIT state before clearing notification signals and utilizing clear_notify_signal to provide necessary memory barriers ensuring visibility of flags across threads. By preserving the signal delivery mechanism for these specific bounded operations, workers are guaranteed to wake up from their sleep states even if they initiate work after the initial broadcast signal was sent. This ensures that all pending I/O operations complete or terminate appropriately during thread exit sequences, restoring normal process lifecycle management and preventing indefinite hangs in io_uring-based applications.