GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring/query: unclamped user size lets a local task request ~4 GiB of clear_user zeroing

UnscoredCVE-2026-81009Kernel, userspace & hypervisorcurated

Impact

io_handle_query_entry() clamped hdr.size for the inbound copy but kept the original user-supplied value for the outbound copy_struct_to_user(), which clear_user()s the trailing bytes. Because hdr.size is a u32, an unprivileged task can ask the kernel to zero close to 4 GiB of user memory, including on the error path where the result size is zero. That is a local denial-of-service primitive against a shared GPU node - burned CPU in kernel context on a machine other tenants are sharing. The interface is reachable through IORING_REGISTER_QUERY without even creating a ring, so any container that has not blocked io_uring by seccomp can hit it.

Who can reach it

Any local user or container task permitted to call io_uring_register. No authentication beyond being able to run code on the node; tenant pods qualify unless io_uring is filtered.

What to do

Update to a stable kernel containing the PAGE_SIZE cap (three backport commits linked) and reboot the node. Until then the practical mitigation is the one many operators already run: disable io_uring for untrusted workloads via the sysctl or a seccomp profile that blocks io_uring_setup/io_uring_register. Kernel rollout on a GPU fleet is a drain-and-reboot per node.

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.