CVE-2026-80811: io_uring/cmd: fix iovec leak when the async cmd is not recycled
In the Linux kernel, the following vulnerability has been resolved:
iouring/cmd: fix iovec leak when the async cmd is not recycled
An ioasynccmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmdcache. On two paths nothing frees it and iocleanop()'s kfree(req->asyncdata) drops the ioasynccmd without it.
iorequringcleanup() clears the async data flags only when ioalloccacheput() succeeds, and the cache holds IOALLOCCACHEMAX == 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: nvmeuringcmdio() returns -EIOCBQUEUED, so the ioasynccmd 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 iorequringcleanup() returns early for an io-wq issued command and is not called at all for one completed without ever being issued. But iocleanop() calls ->cleanup only if REQFNEEDCLEANUP is set, and for uringcmd that happens only where the vec has to grow, so a command reusing a large enough cached vec never sets it. iorwallocasync() and iomsgallocasync() flag an inherited vec for exactly this reason; iouringcmdprep() does not.
Flag an inherited vec in iouringcmdprep(), and free the vec when the cache put fails, as ioreqrwcleanup() does.
The leak is invisible under KASAN, where ioalloccacheveckasan() frees the vec unconditionally.
Affected Software
Event History
Frequently Asked Questions
What workloads are most likely to trigger this issue?
Workloads using io_uring uring_cmd operations with asynchronous commands are exposed. NVMe passthrough is specifically described as reaching the affected path under normal operation, because commands remain attached for their lifetime and the live object count follows queue depth.
What conditions cause the leaked allocations to accumulate?
The command allocation cache can retain up to 128 entries. When the live command count exceeds that level, cache insertion can fail, and an inherited iovec array may not be freed on affected cleanup paths.
Can this occur only after an io-wq worker issues the command?
No. The description identifies both commands issued through io-wq, where normal io_uring cleanup returns early, and commands completed without ever being issued, where that cleanup is not called. The command-specific cleanup path is needed to release the inherited vector in these cases.