Live › vulnerability › CVE-2026-99231
A race in the Linux kernel's io_uring waitid handling can complete a request while its wake-up handler still touches it, leaving a use-after-free. The sources describe the consequence as a KASAN-reported slab use-after-free reachable through socket wake-up, and the sources do not state what an attacker can gain beyond that.
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.
Linux systems whose kernel has io_uring with the IORING_OP_WAITID opcode, where local code can submit waitid requests through io_uring. The bug was introduced by upstream commit ab673c1bcaf2; which released kernel versions contain it is not stated in the sources. Hosts with io_uring disabled (kernel.io_uring_disabled sysctl) or no untrusted local code can deprioritize it. The sources do not say whether unprivileged users can reach it.
No product ranges from the sources yet.
io_uring/waitid: own the request before clearing ->head only clears ->head after the handler owns the requestEach 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/waitid: own the request before clearing ->head
io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it:
CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs)
The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data:
BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950
Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless.
This page as .md · .json · in your agent: get_signal("CVE-2026-99231")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.