AZL-112613: CVE-2026-99255 affecting package kernel 6.6.159.1-1
In the Linux kernel, the following vulnerability has been resolved:
iouring/io-wq: don't hide a link from cancellations
A task that exits cancels its tracked requests and waits until they are gone. iouringcancelgeneric() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed.
When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found:
ioworkerhandlework() ioassigncurrentwork(worker, NULL) iowqfreework(work) ioreqfindnext() // takes the link off the request iofreereq() // task work for the task ioassigncurrentwork(worker, linked) ioruntaskwork() condresched() worker->curwork = linked
It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of iofreereq() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IOWQBITEXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either.
NOP, IOSQEASYNC | IOSQEIOLINK FUTEXWAIT, FUTEX2PRIVATE exit of the thread, or of the process, up to 63us later
With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM):
iouringcancelgeneric doexit
Commit f8b632e89a10 ("iouring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before iofreereq().
Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split iowqfreework() in two.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
kernelto a version that resolves this vulnerability.Patch f8b632e89a10
Event History
Frequently Asked Questions
What race condition is required for this issue to occur?
An exiting task must cancel tracked io_uring requests while a worker is transitioning from one linked request to the next. During this interval, the next request is temporarily neither pending nor assigned as a worker's current work, so cancellation can find nothing and sleep.
Can the worker still run the linked request after the task begins exiting?
Yes. The description states that IO_WQ_BIT_EXIT does not prevent bounded work from running, so the worker can run the linked request after the exiting task has gone to sleep. If that request is parked, no completion or free operation wakes the task.