GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring uring_cmd: iovec leak under NVMe passthrough once the alloc cache fills

UnscoredCVE-2026-80811Kernel, userspace & hypervisorcurated

Impact

An io_async_cmd carries an iovec array that is meant to survive recycling through the per-context command cache. On two paths nothing frees it: io_req_uring_cleanup() clears the async-data flags only when the cache put succeeds, and the cache holds 128 entries, so above that depth the puts fail and the vec is dropped on the floor. io_uring_cmd_prep() also never flags an inherited vec for cleanup the way the read/write and msg paths do, so a command reusing a large enough cached vec never takes the ->cleanup path at all. An NVMe passthrough workload reaches this without doing anything unusual - the command stays attached for its lifetime, so live objects track queue depth and anything above 128 leaks. The result is a slow unprivileged kernel memory leak on a shared node, which ends in an OOM and a drain rather than in code execution. It is invisible under KASAN, which frees the vec unconditionally, so it will not show up in a debug-kernel soak.

Who can reach it

Local user able to submit io_uring uring_cmd operations - in practice a tenant with NVMe passthrough (/dev/ngX) exposed to it, running at queue depth above 128. No authentication beyond having the device.

What to do

Take the stable kernel fix: it flags an inherited vec in io_uring_cmd_prep() and frees the vec when the cache put fails. Kernel change, so nodes reboot onto the patched kernel unless you livepatch; a daemon restart does not clear the leaked memory. Not exposing NVMe passthrough character devices into tenant containers removes the practical path in the meantime.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.