CVE-2026-99231

Status: UPDATED  |  Advisory ID: CVE-2026-99231

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References