Cloudanix VulnDB

CVE-2026-99262

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can let certain input-output operations ignore cancellation requests, causing programs to get stuck when they try to shut down cleanly.

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

Race condition in io_uring timeout handling where IO_WQ_WORK_CANCEL flag is checked only once before io-wq submission; a concurrent cancel sets the flag and returns -EALREADY but the worker later adds the request to timeout_list and starts the hrtimer without rechecking under timeout_lock, allowing the timeout to run to completion.

Why it matters to the business

Linux systems using io_uring with async timeouts may experience prolonged hangs during process or ring exit, degrading availability and reliability of I/O-heavy workloads until the timeout duration elapses.

How an attack unfolds

An attacker triggers an async IORING_OP_TIMEOUT via io-wq, then issues a precise cancel between the initial flag check and the timeout_list insertion; the lost cancel leaves the timer active, and on ring exit io_uring_try_cancel_requests cannot terminate it promptly.

How to fix it

Upgrade to a Linux kernel containing the io_uring/timeout fix that rechecks the cancel flag under timeout_lock; rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the patched kernel source contains the timeout_lock-protected check for IO_WQ_WORK_CANCEL before adding to timeout_list; test io_uring cancel paths with concurrent async timeouts.

Typical attack path

  1. Submit IORING_OP_TIMEOUT with IOSQE_ASYNC flag
  2. Race io_try_cancel / io_async_cancel_one to set IO_WQ_WORK_CANCEL
  3. Observe io_timeout proceeding to add request and start hrtimer
  4. Trigger ring exit to observe hang for full timeout duration

How to detect it

Examine kernel logs and process traces for io_uring ring-exit stalls involving active timeout_list entries; search for repeated io_timeout or hrtimer activity after cancel attempts.

What your security team should do

  • Prioritize kernel updates on systems using io_uring
  • Review workloads for heavy async timeout usage and consider temporary mitigation via synchronous submission
  • Monitor kernel mailing lists for backported fixes in distribution kernels

The record

In the Linux kernel, the following vulnerability has been resolved: io_uring/timeout: don't lose a cancel as io-wq arms a timeout An IORING_OP_TIMEOUT run by io-wq, because of IOSQE_ASYNC, has the same problem as poll, futex and waitid. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain, while the worker then adds the request and starts the timer: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() adds the request to ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again, and the timeout runs its course. At ring exit, io_uring_try_cancel_requests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout. Look at the flag under ->timeout_lock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list.

Affected packages

Ecosystem Package Introduced Fixed