GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring: legacy buffer recycle does not re-check that the buffer list still exists or is legacy

CVSS 7.8CVE-2026-43366Kernel, userspace & hypervisorcurated

Impact

Between grabbing a provided buffer and recycling it, another thread can free the buffer list or upgrade it to the ring-provided type - a window that opens when a request is punted to io-wq. The legacy recycle path did not re-check that the buffer_list still existed or was still of the legacy type, so it operates on freed or type-confused state. io_uring is unprivileged by default and is the hot path for modern storage and inference I/O, so on a shared GPU node the reachable attacker is an ordinary tenant process; NVD rates it 7.8 local with high confidentiality, integrity and availability impact, i.e. plausible container escape to host root on a node you cannot drain cheaply because its GPUs are mid-job. Five stable branches carry backports, so this is not confined to the newest kernels.

Who can reach it

Local, any authenticated user or container process that can call io_uring_setup() and register provided buffers - no capabilities required unless io_uring has been restricted. Winning the race needs a request forced through io-wq, which userspace can arrange.

What to do

Patch to a stable kernel with the added checks and reboot; io_uring is built into the kernel, so there is no restart-the-daemon option. If a reboot window is far off, io_uring_disabled=2 (or a seccomp filter blocking io_uring_setup) shuts the interface for tenant workloads - verify first that your runtime and storage stack do not depend on it, since several do.

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.