Cloudanix VulnDB

CVE-2026-99130

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A local user can make the Linux kernel get stuck using an entire CPU core or crash the whole system.

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

What it actually does

io_uring_cancel_generic spins indefinitely on local work for IORING_SETUP_DEFER_TASKRUN rings that the exiting task cannot run, tripping WARN_ON_ONCE and burning CPU or panicking the kernel when panic_on_warn is enabled.

Why it matters to the business

A local user can force a CPU core to spin forever or trigger a kernel panic, causing denial of service, loss of availability, and potential data corruption on affected systems.

How an attack unfolds

An unprivileged local attacker creates a disabled io_uring ring, arranges for another task to enable it, posts work that only the other task can complete, then exits while requests remain in flight, causing the kernel to spin in do_exit instead of sleeping.

How to fix it

Update to a kernel containing the fix that replaces the unconditional spin with a check against io_allowed_defer_tw_run before deciding to sleep; apply the latest stable kernel for the distribution once available.

How to confirm the fix worked

Confirm the presence of the upstream commit that adds the io_allowed_defer_tw_run guard and removes the WARN_ON_ONCE; verify no WARN messages appear in dmesg during exit of tasks using deferred rings.

Typical attack path

  1. Create io_uring instance with IORING_SETUP_R_DISABLED
  2. Have child or other task call IORING_REGISTER_ENABLE_RINGS
  3. Post IORING_OP_MSG_RING or similar request that only the other task can complete
  4. Exit the original task with the request still pending
  5. Trigger io_uring_cancel_generic spin loop and optional kernel panic

How to detect it

Review kernel logs for the WARN_ON_ONCE message emitted by io_uring_cancel_generic; inspect dmesg and journalctl for repeated warnings during process exit involving io_uring; correlate with processes that create rings and then terminate quickly.

What your security team should do

  • Prioritize kernel updates on multi-user or container hosts where unprivileged users can create io_uring rings
  • Monitor for rapid kernel updates from distributions and schedule deployment within normal change windows
  • Consider temporarily disabling io_uring via sysctl or seccomp where the feature is not required

The record

In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: don't spin on local work the task can't run io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit(). An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel. Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state.

Affected packages

Ecosystem Package Introduced Fixed