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 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.