CVE-2026-99231: io_uring/waitid: own the request before clearing ->head

In the Linux kernel, the following vulnerability has been resolved:

iouring/waitid: own the request before clearing ->head

iowaitidremovewq() only takes the wait queue lock if ->head is set. iowaitidwait() 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 (iowaitidwait) CPU1 (iowaitid, holds a ref) listdelinit(&wait->entry) smpstorerelease(&iw->head, NULL) dowait() finds another child iowaitidremovewq() // ->head == NULL, no locking iowaitidfinish(), IOUCOMPLETE // request freed and reused atomicfetchinc(&iw->refs)

The same goes for iowaitidcancel() 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 iowaitidcb() 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 wakeupcommon+0x1ca/0x1f0 wakeupsynckey+0x36/0x50 sockdefreadable+0xf1/0x420 unixstreamsendmsg+0x60b/0x1110 Allocated by task 87: ioarmapoll+0x1ed/0x940 Freed by task 87: iosubmitflushcompletions+0x118d/0x1a10 tctxtaskworkrun+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.