io_uring/wait: don't spin on a stuck overflow list
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: The record gives no workaround. The only trigger it names is the IORING_SETUP_CQE_MIXED ring setup, so limiting use of that setting would narrow the conditions described, but the record does not confirm that this is a supported mitigation.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 25/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's io_uring subsystem is affected. A flaw in how it waits for completion events can cause a process to spin indefinitely inside the kernel when the completion queue overflow list cannot be flushed, leaving the process unkillable, even by SIGKILL.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: io_uring/wait: don't spin on a stuck overflow list As long as IO_CHECK_CQ_OVERFLOW_BIT is set, io_cqring_wait_schedule() returns right away, before it gets to look at signals or arms the timeout, for io_cqring_wait() 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 min_events is capped to the size of the ring. But: • With IORING_SETUP_CQE_MIXED 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 cq_entries events. A single threaded application that asks for as many events as the ring has entries never gets out of io_uring_enter(). • 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.
What to do
Workaround: The record gives no workaround. The only trigger it names is the IORING_SETUP_CQE_MIXED ring setup, so limiting use of that setting would narrow the conditions described, but the record does not confirm that this is a supported mitigation.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
6.3
Evidence 4
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99229
What does this mean?
In the Linux kernel's io_uring wait path, a task waiting for events on the completion queue can spin in the kernel and cannot be killed, not even by SIGKILL, which is a denial of service. The record says this happens when a ring is set up with IORING_SETUP_CQE_MIXED and another thread moves the CQ head so the ring looks full, causing a completion overflow.Source: git.kernel.org
Am I affected, and how do I check?
The record lists the product as the Linux kernel but gives no affected version ranges. The stated conditions are an io_uring ring set up with IORING_SETUP_CQE_MIXED and a thread waiting on the CQ ring while another thread moves the CQ head. To check a system, look at the kernel version and whether the software it runs creates io_uring rings with that flag.Source: git.kernel.org
What should I do about it?
The record does not name a fixed version or a fix commit, so no upgrade target can be given from these facts. Check the kernel's own advisory or stable release notes for the version that contains the fix.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
The record gives no workaround. The only trigger it names is the IORING_SETUP_CQE_MIXED ring setup, so limiting use of that setting would narrow the conditions described, but the record does not confirm that this is a supported mitigation.Source: git.kernel.org