Description
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.
Published: 2026-11-03
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Immediate Patch
AI Analysis

Impact

In the Linux kernel, a race condition in the io_uring timeout subsystem causes a cancellation request to be ignored when a work queue arms a timeout. This defect lets the operation that issued the timeout stay blocked for the full timeout duration, effectively suspending the task and potentially exhausting system resources. The flaw is a classic concurrency bug that undermines the integrity of asynchronous I/O handling. The issue was identified in the kernel's handling of IOSQE_ASYNC and io_try_cancel interactions.

Affected Systems

All Linux kernel releases are affected; no specific version numbers are listed. The problem manifests when io_uring is used on a system running a vulnerable kernel, regardless of distribution.

Risk and Exploitability

No publicly documented CVSS or EPSS metrics, and the vulnerability is not listed in the CISA KEV catalog, indicating limited exposure data. The likely attack vector is local to a user with permission to submit io_uring requests and issue cancellations – this inference is drawn from the description of the race condition involving io_wq_submit_work and io_try_cancel. An attacker could exploit the timing condition to keep a task blocked for the entirety of a timeout interval, leading to denial of service on the local machine. The risk remains moderate to high for environments where io_uring is enabled and no mitigation has been applied.

Generated by OpenCVE AI on November 3, 2026 at 13:53 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version where this issue is fixed
  • Disable io_uring support in the kernel configuration if the functionality is not required
  • Implement monitoring to detect tasks that remain blocked beyond the expected timeout and restart or recover them

Generated by OpenCVE AI on November 3, 2026 at 13:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 03 Nov 2026 14:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Weaknesses CWE-400
CWE-847
Vendors & Products Linux linux

Tue, 03 Nov 2026 12:00:00 +0000

Type Values Removed Values Added
Description 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.
Title io_uring/timeout: don't lose a cancel as io-wq arms a timeout
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-11-03T11:48:15.294Z

Reserved: 2026-09-25T10:25:14.404Z

Link: CVE-2026-99262

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-03T12:17:33.210

Modified: 2026-11-03T12:17:33.210

Link: CVE-2026-99262

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-11-03T14:00:19Z

Weaknesses