Cloudanix VulnDB

CVE-2026-80811

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can slowly leak memory when certain fast storage commands are used repeatedly, eventually risking slowdowns or crashes on busy systems, though attackers are not known to be exploiting it.

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

What it actually does

Memory leak of iovec arrays stored in io_async_cmd structures when io_alloc_cache_put fails after the cache reaches 128 entries or when certain unissued io-wq command paths skip cleanup, occurring in io_uring cmd handling for workloads such as NVMe passthrough.

Why it matters to the business

Gradual memory exhaustion on Linux systems running io_uring-heavy workloads with queue depths above 128, increasing operational risk of OOM kills or degraded performance over extended periods; low immediate urgency given the absence of known exploitation and stable low exploit probability.

How an attack unfolds

An attacker with local access triggers repeated io_uring commands that grow and cache iovecs (such as NVMe passthrough operations returning -EIOCBQUEUED) until the fixed-size cache fills, after which subsequent commands leak the arrays because cleanup flags are not set on reused cached vectors and early returns bypass freeing.

How to fix it

Apply the upstream kernel patch that flags inherited vectors in io_uring_cmd_prep and frees them on cache-put failure; rebuild and deploy the fixed kernel version containing the io_uring/cmd change resolving the leak.

How to confirm the fix worked

Confirm the patch is present by inspecting the io_uring/cmd.c source for the added flag and free logic; monitor memory usage under sustained io_uring workloads with queue depths exceeding 128 to verify no progressive iovec leaks occur.

Typical attack path

  1. Obtain local execution context on a Linux host using io_uring
  2. Issue high volumes of uring commands that allocate and cache iovec arrays (e.g., NVMe passthrough)
  3. Drive queue depth above the 128-entry cache limit to cause put failures
  4. Allow leaked memory to accumulate until system memory pressure occurs

How to detect it

Review kernel memory accounting and slab statistics for unexpected growth in io_uring related objects; correlate with high-volume io_uring command traces from workloads exceeding cache limits; no public exploit artifacts or threat-actor campaigns are associated with this issue.

What your security team should do

  • Prioritize kernel updates on systems with heavy io_uring usage (NVMe, high-performance storage)
  • Monitor memory metrics on affected hosts during peak io_uring activity
  • Review io_uring adoption in internal workloads to assess exposure breadth

The record

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.

Affected packages

Ecosystem Package Introduced Fixed