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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
No data available yet.
No solution or workaround provided in the CVE record.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
Mon, 02 Nov 2026 16:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | io_uring/wait: don't spin on a stuck overflow list | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-11-02T16:06:37.423Z
Reserved: 2026-09-25T10:25:14.402Z
Link: CVE-2026-99229
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-11-02T16:17:47.780
Modified: 2026-11-02T16:17:47.780
Link: CVE-2026-99229
Redhat
No data.
OpenCVE Enrichment
Updated: 2026-11-02T17:45:12Z
No weakness.