Description
In the Linux kernel, the following vulnerability has been resolved:

io_uring/cmd: fix iovec leak when the async cmd is not recycled

An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the
vec has to grow and kept across recycling through ctx->cmd_cache. On two
paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops
the io_async_cmd without it.

io_req_uring_cleanup() clears the async data flags only when
io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX ==
128 entries, so once it is full the put fails and the vec is left behind.
An NVMe passthrough workload gets there without doing anything unusual:
nvme_uring_cmd_io() returns -EIOCBQUEUED, so the io_async_cmd stays
attached for the lifetime of the command and the live object count tracks
the queue depth. Above 128 the puts start failing.

->cleanup is the last chance to free an inherited vec, since
io_req_uring_cleanup() returns early for an io-wq issued command and is
not called at all for one completed without ever being issued. But
io_clean_op() calls ->cleanup only if REQ_F_NEED_CLEANUP is set, and for
uring_cmd that happens only where the vec has to grow, so a command
reusing a large enough cached vec never sets it. io_rw_alloc_async() and
io_msg_alloc_async() flag an inherited vec for exactly this reason;
io_uring_cmd_prep() does not.

Flag an inherited vec in io_uring_cmd_prep(), and free the vec when the
cache put fails, as io_req_rw_cleanup() does.

The leak is invisible under KASAN, where io_alloc_cache_vec_kasan() frees
the vec unconditionally.
Published: 2026-09-04
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel’s io_uring subsystem has a flaw that can cause an iovec array to remain allocated when asynchronous commands are not properly recycled. The bug allows an allocation to survive beyond its intended life cycle, leaking kernel memory. If exploited repeatedly, the accumulation of these leaks can consume significant kernel memory, potentially degrading system performance or causing a denial‑of‑service condition.

Affected Systems

All Linux kernel builds that include io_uring support are affected, regardless of vendor or distribution. The vulnerability exists in the kernel’s io_async_cmd handling and therefore applies to any host running a kernel where the io_uring code has not been patched. No specific kernel release numbers are provided, so any active system with io_uring enabled is potentially vulnerable.

Risk and Exploitability

The issue is not currently listed in the CISA KEV catalogue and no EPSS score is available, indicating no public evidence of exploitation. In a typical scenario, a privileged or inter‑process user can submit many io_uring commands—particularly NVMe passthrough operations—to trigger the leak whenever the queue depth exceeds 128 entries. Because the leak occurs in kernel address space, it does not provide direct code execution but can exhaust memory resources, leading to degraded availability. The severity is therefore moderate, with the main risk being resource exhaustion rather than direct privilege escalation or data disclosure.

Generated by OpenCVE AI on September 4, 2026 at 17:29 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version where the io_uring iovec leak is fixed (see kernel commit logs linked above).
  • Configure io_uring usage to limit the queue depth to 128 or fewer commands, or disable NVMe passthrough if not required.
  • Monitor kernel memory usage (e.g., vmstat, top, /proc/meminfo) for abnormal growth patterns that may indicate a memory leak, and reboot or apply a patch when suspicious activity is detected.

Generated by OpenCVE AI on September 4, 2026 at 17:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 04 Sep 2026 17:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401

Fri, 04 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd: fix iovec leak when the async cmd is not recycled An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmd_cache. On two paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without it. io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX == 128 entries, so once it is full the put fails and the vec is left behind. An NVMe passthrough workload gets there without doing anything unusual: nvme_uring_cmd_io() returns -EIOCBQUEUED, so the io_async_cmd stays attached for the lifetime of the command and the live object count tracks the queue depth. Above 128 the puts start failing. ->cleanup is the last chance to free an inherited vec, since io_req_uring_cleanup() returns early for an io-wq issued command and is not called at all for one completed without ever being issued. But io_clean_op() calls ->cleanup only if REQ_F_NEED_CLEANUP is set, and for uring_cmd that happens only where the vec has to grow, so a command reusing a large enough cached vec never sets it. io_rw_alloc_async() and io_msg_alloc_async() flag an inherited vec for exactly this reason; io_uring_cmd_prep() does not. Flag an inherited vec in io_uring_cmd_prep(), and free the vec when the cache put fails, as io_req_rw_cleanup() does. The leak is invisible under KASAN, where io_alloc_cache_vec_kasan() frees the vec unconditionally.
Title io_uring/cmd: fix iovec leak when the async cmd is not recycled
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 Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T15:13:31.761Z

Reserved: 2026-08-26T14:34:25.794Z

Link: CVE-2026-80811

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T16:18:08.497

Modified: 2026-09-04T16:18:08.497

Link: CVE-2026-80811

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T17:30:17Z

Weaknesses
  • CWE-401

    Missing Release of Memory after Effective Lifetime