CVE-2026-99229: io_uring/wait: don't spin on a stuck overflow list
In the Linux kernel, the following vulnerability has been resolved:
iouring/wait: don't spin on a stuck overflow list
As long as IOCHECKCQOVERFLOWBIT is set, iocqringwaitschedule() returns right away, before it gets to look at signals or arms the timeout, for iocqringwait() to flush the overflow list. If that doesn't empty the list, and the CQ ring doesn't hold the number of events the caller wants, the loop starts over, with the same result. The task spins in the kernel, and can't be killed.
The assumption is that this can't happen: if CQEs can't be flushed, the ring is full, and minevents is capped to the size of the ring. But:
- With IORINGSETUPCQEMIXED a 32b CQE needs two contiguous entries. It is stuck on the list if a single one is free, and then the ring holds less than cqentries events. A single threaded application that asks for as many events as the ring has entries never gets out of iouringenter().
- Whether the ring is full is up to the CQ head, which the application can write to. While one thread waits for events on an empty ring, another one can move the head back so that the ring looks full and have a CQE overflow. The waiter can't be stopped any more, not even by SIGKILL.
Only the application can make room in the CQ ring. Return to it if the list could not be flushed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.161 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.115 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.60 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.14
Event History
Frequently Asked Questions
What conditions can trigger the unkillable kernel spin?
The issue can occur when completion queue entries remain on the io_uring overflow list and cannot be flushed while the caller is waiting for more events. Two described triggers are use of IORING_SETUP_CQE_MIXED with only one free CQ entry for a 32-bit CQE, or another thread moving the application-controlled CQ head so the ring appears full while a waiter is blocked.
Is a default io_uring setup affected?
The mixed-CQE trigger specifically requires IORING_SETUP_CQE_MIXED. The other described scenario requires multiple threads sharing a ring, with one thread able to modify the CQ head while another waits for events.
What is the operational impact if exploitation succeeds?
A task can spin in the kernel inside io_uring_enter() and cannot be killed. This can leave the affected waiting task consuming CPU rather than honoring signals or timeouts.
How can I identify a potentially affected workload?
Look for applications using io_uring that wait for a number of completions equal to the CQ ring size, especially when IORING_SETUP_CQE_MIXED is enabled. Also review shared, multithreaded rings where one thread can update the CQ head while another thread is waiting for completions.