Live › vulnerability › CVE-2026-99230
A flaw in the Linux kernel's io_uring subsystem leaves a stale list pointer in a recycled request, so a woken vectored futex wait can dereference it. The sources describe a general protection fault (kernel crash) and do not state that an attacker can run code.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 16:24 UTC. All times on this page are UTC.
The sources describe a path that needs a cancelable io_uring command (for example a ublk FETCH_REQ) followed by a vectored futex wait that is woken during setup. Systems running Linux kernels that include the io_uring code without this change are the ones to look at, especially hosts running ublk or io_uring-heavy workloads. Systems without io_uring or ublk in use are likely not reachable through this path, though the sources do not state that explicitly.
No product ranges from the sources yet.
uname -r and compare the kernel version with the fixed versions in the kernel stable branches once published.cat /proc/sys/kernel/io_uring_disabled (unknown whether this is conclusive).ublk_drv) is loaded with lsmod | grep ublk, since the sources cite a ublk FETCH_REQ path.Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99230")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.