CVE-2026-99230 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/cmd: don't leave list poison in ->hash_node
io_uring_cmd_del_cancelable() uses hlist_del() to take a command off ->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in ->hash_node. Requests are recycled through the request cache without being reinitialised, and not every user of ->hash_node sets it up before it is used:
If a vectored futex wait is woken while futex_wait_multiple_setup() is still queueing the futexes, io_futexv_wait() doesn't add the request to ->futex_list, and leaves the completion to the task_work queued by the wake up. io_futexv_complete() ends in __io_futex_complete(), whose hlist_del_init() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through LIST_POISON2:
Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...]
RIP: 0010:io_futexv_complete+0x219/0x420 Call Trace: tctx_task_work_run+0x804/0x950 tctx_task_work+0x71/0xa0 task_work_run+0x118/0x200
Leave the node unhashed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel io_uring subsystem contains a critical use-after-free and memory corruption vulnerability stemming from improper list management within command cancellation logic. Specifically, the function io_uring_cmd_del_cancelable() utilizes hlist_del to remove a request from the cancelable uring command queue. This operation leaves LIST_POISON1 and LIST_POISON2 values embedded in the ->hash_node structure of the request object. These poison values are diagnostic markers used by kernel debugging features like KASAN to detect invalid memory accesses, but their presence here creates a severe integrity issue when requests are recycled from the internal cache without being fully reinitialized for subsequent operations.
The core technical flaw arises because io_uring recycles request structures across multiple submissions and completions to optimize performance. However, not all code paths that interact with the ->hash_node field ensure it is properly cleared or initialized before use. In particular, when handling vectored futex waits, if a wait operation is woken while futex_wait_multiple_setup() is still in the process of queueing futexes, io_futexv_wait fails to add the request to the ->futex_list. Instead, it relies on task_work queued by the wake-up mechanism for completion handling. This path leads directly to io_futexv_complete and subsequently __io_futex_complete, which calls hlist_del_init(). While this function is safe for requests that are already unhashed, it becomes catastrophic if the request was previously a cancelable uring command, such as a ublk FETCH_REQ, because the node still contains the LIST_POISON2 marker.
The operational impact of this vulnerability manifests as a general protection fault caused by wild memory access through non-canonical addresses derived from the poison values. When __io_futex_complete attempts to manipulate the hash list using hlist_del_init on a request containing these poisoned pointers, it triggers an Oops error within the kernel space. This results in immediate process termination and potential system instability or denial of service depending on the context. The vulnerability effectively allows local users with appropriate privileges to crash the kernel by crafting specific io_uring submission patterns that exploit this race condition between cancellation cleanup and futex completion logic.
This issue aligns with CWE-416, Use After Free, as it involves accessing memory structures in an invalid state due to improper lifecycle management of object references within the kernel's asynchronous I/O framework. From a threat modeling perspective using MITRE ATT&CK techniques, this vulnerability can be leveraged for Local Privilege Escalation or Denial of Service by triggering kernel panics through crafted system calls that exploit the race condition in task work execution and list manipulation. The attack vector requires local access to invoke io_uring commands with specific cancellation characteristics followed immediately by vectored futex operations, making it a targeted exploitation scenario rather than a remote network-based threat.
Mitigation strategies primarily involve applying kernel patches that address this specific logic error in the io_uring subsystem. System administrators should ensure their Linux kernels are updated to versions where the fix for leaving list poison in ->hash_node is applied. The resolution involves modifying the cancellation and completion paths to explicitly leave the node unhashed rather than relying on implicit state assumptions during request recycling. Additionally, developers integrating with or extending io_uring functionality must adhere strictly to initialization protocols for all hash nodes before they are reused across different command types. Regular security auditing of kernel code that interacts with shared resource caches is essential to prevent similar lifecycle management flaws in asynchronous I/O operations.