---
id: "CVE-2026-99229"
kind: "vulnerability"
aliases: ["CVE-2026-99229"]
title: "Linux kernel: io_uring wait loop can spin forever and ignore kill signals"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["io_uring", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["io_uring-disabled", "no-cqe-mixed"]
published_at: "2026-11-02T16:17:47+00:00"
first_seen_at: "2026-11-02T16:24:06+00:00"
updated_at: "2026-11-02T16:26:54+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99229", "first_seen_at": "2026-11-02T16:24:06+00:00"}]
---

# Linux kernel: io_uring wait loop can spin forever and ignore kill signals

A bug in the Linux kernel's io_uring wait path can leave a task spinning in kernel mode when completion-queue overflow entries cannot be flushed. The stuck task cannot be killed, even by SIGKILL, which lets a local or application-level actor tie up a process indefinitely.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the kernel version with `uname -r` and compare it against the fixed release in the kernel stable tree referenced by NVD.
- Find processes that use io_uring with `IORING_SETUP_CQE_MIXED` or that spin in kernel mode (state `R` with high CPU in `top`).

## Timeline

- 2026-11-02T16:24:06+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99229

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_