Cloudanix VulnDB

CVE-2026-99229

None

CVSS

—

EPSS

0.2%

Published

Nov 2, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in the Linux kernel can cause certain programs to freeze permanently and ignore shutdown commands, potentially requiring a computer restart.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A flaw in io_uring's wait mechanism allows a task to spin indefinitely in the kernel when the CQ overflow list cannot be flushed due to ring configuration or concurrent head manipulation, preventing signal handling and making the task unkillable.

Why it matters to the business

Applications using io_uring can become unresponsive and unkillable, leading to resource exhaustion and requiring system reboots to recover affected processes. The issue was disclosed only one day ago with no known exploitation yet.

How an attack unfolds

An attacker crafts an io_uring setup with mixed CQEs or uses multiple threads to manipulate the CQ head pointer while another thread waits, causing the waiter to loop indefinitely without checking for termination signals.

How to fix it

Apply the upstream Linux kernel patch that resolves the stuck overflow list handling in io_cqring_wait_schedule and io_cqring_wait.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the io_uring wait code for proper signal and timeout checks before returning from io_cqring_wait_schedule; test with mixed CQE configurations and concurrent CQ head updates.

Typical attack path

  1. Configure an io_uring ring using IORING_SETUP_CQE_MIXED or similar flags
  2. Trigger CQ overflow conditions by submitting events that exceed immediate ring capacity
  3. Use a concurrent thread to advance the CQ head pointer to simulate a full ring
  4. Initiate a wait from another thread that enters an unkillable spin loop in the kernel

How to detect it

Inspect kernel logs and process state for tasks stuck in io_uring wait paths that resist SIGKILL; correlate with recent io_uring ring setup and overflow events.

What your security team should do

  • Prioritize kernel upgrades on all systems that enable io_uring in user workloads
  • Review and restrict io_uring usage in untrusted or multi-threaded applications until patched
  • Monitor process listings for D-state tasks associated with io_uring_enter

The record

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.

Affected packages

Ecosystem Package Introduced Fixed