CVE-2026-80811

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.