UBUNTU-CVE-2026-99253: Medium severity ubuntu/linux vulnerability

In the Linux kernel, the following vulnerability has been resolved: iouring/cancel: rearm local work wake up before sleep iouringtrycancelrequests() sets ->cqwaitnr to 1 so that the next ioreqlocalworkadd() 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. iouringcancelgeneric() however only becomes TASKINTERRUPTIBLE 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 iolocalworkpending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (ioreqlocalworkadd) mpscqpush(req A) iouringtrycancelrequests() iorunlocalwork() // runs req A iouringtrycancelrequests() atomicset(&ctx->cqwaitnr, 1) atomicread(&ctx->cqwaitnr) == 1 count taken, wakeupstate() // task is running, no-op preparetowait(TASKINTERRUPTIBLE) iolocalworkpending() == false schedule() mpscqpush(req B) cqwaitnr <= 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.