GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring/waitid: use-after-free when the wake handler clears ->head before owning the request

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

Impact

io_waitid_wait() clears iw->head before it claims ownership of the request by incrementing ->refs. If another path already owns the request, that path can complete and free it while the wake-up handler is still touching it, and the handler then increments whatever the reused request's per-opcode data holds. The reported KASAN trace shows a slab-use-after-free reached through __wake_up_common. On a GPU node this is a local privilege-escalation primitive available to any unprivileged process allowed to use io_uring, including code inside a tenant container unless io_uring is blocked by seccomp. It matters most on multi-tenant GPU hosts, where host root means access to every other tenant's GPU context, and where taking the node out of service to patch costs a drain of long-running training jobs.

Who can reach it

Local unprivileged user or container process that can issue io_uring IORING_OP_WAITID operations and race a cancellation. No remote path and no authentication beyond code execution on the node.

What to do

Pick up the stable kernel commits referenced in the advisory, or the distro kernel that carries them, then drain and reboot each GPU node; a live kernel patch is not published for this. Where patching has to wait, blocking io_uring for tenant workloads (seccomp filter on io_uring_setup, or kernel.io_uring_disabled) removes the attack surface without a reboot.

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.