CVE-2026-80811 Overview
CVE-2026-80811 is a memory leak vulnerability in the Linux kernel's io_uring/cmd subsystem. The flaw affects the handling of io_async_cmd structures that carry an iovec array in ->vec.iovec. When the asynchronous command is not recycled through ctx->cmd_cache, the inherited iovec is never freed. NVMe passthrough workloads that return -EIOCBQUEUED from nvme_uring_cmd_io() trigger the condition once the cache exceeds its 128-entry limit. The leak is invisible under Kernel Address Sanitizer (KASAN), which frees the vec unconditionally via io_alloc_cache_vec_kasan().
Critical Impact
Sustained kernel memory exhaustion in workloads that queue io_uring commands above the allocation cache limit, potentially leading to denial of service on long-running systems.
Affected Products
- Linux kernel versions containing the io_uring/cmd async command handling code
- Systems using NVMe passthrough with io_uring command interface
- Workloads that maintain io_uring command queue depths exceeding 128 concurrent operations
Discovery Timeline
- 2026-09-04 - CVE-2026-80811 published to NVD
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80811
Vulnerability Analysis
The vulnerability resides in the Linux kernel io_uring command path. An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec must grow. The kernel keeps this allocation across recycling through ctx->cmd_cache. On two code paths, nothing frees the iovec, and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without releasing the vec.
The function io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds. The cache holds IO_ALLOC_CACHE_MAX == 128 entries. Once full, the put operation fails and the vec remains allocated.
Root Cause
The root cause is a missing cleanup flag on inherited iovecs in io_uring_cmd_prep(). The ->cleanup callback is the last opportunity to free an inherited vec because io_req_uring_cleanup() returns early for io-wq issued commands and is never called for commands completed without being issued. However, io_clean_op() invokes ->cleanup only when REQ_F_NEED_CLEANUP is set. For uring_cmd, that flag is set only when the vec must grow, so a command reusing a cached vec never triggers it. Similar paths io_rw_alloc_async() and io_msg_alloc_async() correctly flag inherited vecs, but io_uring_cmd_prep() did not.
Attack Vector
A local user process submitting NVMe passthrough commands via io_uring can trigger the leak without exploiting any unusual behavior. The nvme_uring_cmd_io() function returns -EIOCBQUEUED, so the io_async_cmd stays attached for the command's lifetime. When live command counts exceed 128, cache puts fail and each subsequent command leaks its iovec allocation. Sustained workloads exhaust kernel memory over time.
Detection Methods for CVE-2026-80811
Indicators of Compromise
- Progressive growth of kernel slab memory allocated for kmalloc iovec buffers on systems running high-queue-depth io_uring workloads
- NVMe passthrough workloads exhibiting unbounded memory growth without corresponding user-space allocation increases
- Kernel Slab and SUnreclaim counters in /proc/meminfo trending upward on long-running hosts using io_uring command interface
Detection Strategies
- Enable KASAN and slab tracking (CONFIG_SLUB_DEBUG, slub_debug=U) in test environments to trace allocations originating from io_uring_cmd code paths
- Compare kernel build hashes against upstream fix commits 7068d35, b290de4, b6a768a, and bb34ae5 to identify unpatched systems
- Monitor per-process io_uring command queue depths using bpftrace or perf probes on io_uring_cmd_prep and io_req_uring_cleanup
Monitoring Recommendations
- Track kernel slab allocator statistics for the specific cache backing iovec allocations on production Linux hosts
- Alert on sustained growth in SUnreclaim memory that does not correspond to expected workload changes
- Instrument NVMe passthrough consumers to log queue depth peaks and correlate them with kernel memory metrics
How to Mitigate CVE-2026-80811
Immediate Actions Required
- Apply the upstream kernel patches referenced by commits 7068d35, b290de4, b6a768a, and bb34ae5 to affected kernel branches
- Identify systems running NVMe passthrough workloads with io_uring queue depths above 128 and prioritize patching
- Schedule reboots for long-running hosts showing symptoms of kernel memory pressure attributable to this leak
Patch Information
The fix flags an inherited vec in io_uring_cmd_prep() and frees the vec when the cache put fails, matching the behavior of io_req_rw_cleanup(). Patch commits are available in the upstream stable tree: Kernel Git Commit 7068d35, Kernel Git Commit b290de4, Kernel Git Commit b6a768a, and Kernel Git Commit bb34ae5.
Workarounds
- Reduce sustained io_uring command queue depths below the IO_ALLOC_CACHE_MAX threshold of 128 concurrent operations where workload requirements permit
- Restart processes that hold long-lived io_uring rings on a scheduled basis to release accumulated iovec allocations
- Where feasible, avoid using io_uring NVMe passthrough on unpatched kernels and fall back to standard block I/O submission paths
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.