CVE-2026-99253

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.