Live › vulnerability › CVE-2026-99253
A race in the Linux kernel's io_uring cancellation path can cause a task to sleep while a queued io_uring request is never run. The task then stays blocked in execve() or exit until a signal wakes it.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 12:20 UTC. All times on this page are UTC.
Systems running a Linux kernel with io_uring enabled, where processes use io_uring and call exec or exit. The sources do not say which kernel versions are affected or whether the impact is more than a hang. Hosts with io_uring disabled or without io_uring workloads are likely unaffected.
No product ranges from the sources yet.
uname -r and compare it against the fixed versions in the kernel stable branches.cat /proc/sys/kernel/io_uring_disabled.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/cancel: rearm local work wake up before sleep
io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry:
CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return
Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that.
Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run.
This page as .md · .json · in your agent: get_signal("CVE-2026-99253")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.