---
id: "CVE-2026-99262"
kind: "vulnerability"
aliases: ["CVE-2026-99262"]
title: "Linux kernel: io_uring timeout cancel can be lost, stalling exiting tasks"
severity: "low"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["io_uring", "kernel", "linux", "runtime"]
not_affected_if: ["io-uring-disabled"]
published_at: "2026-11-03T12:17:33+00:00"
first_seen_at: "2026-11-03T12:20:40+00:00"
updated_at: "2026-11-03T12:22:42+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99262", "first_seen_at": "2026-11-03T12:20:40+00:00"}]
---

# Linux kernel: io_uring timeout cancel can be lost, stalling exiting tasks

In the Linux kernel's io_uring, a cancel request that arrives while an io-wq worker is starting a timeout can be dropped, so the timeout keeps running. An exiting task can then stay stuck for the full timeout duration.

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

## Timeline

- 2026-11-03T12:20:40+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99262

## From the sources

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.

---

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