GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring poll: cancel flag makes the ownership slowpath unreachable

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

Impact

io_poll_get_ownership() compared the poll reference count as a signed int. Once IO_POLL_CANCEL_FLAG (bit 31) is set the value reads as negative, the >= IO_POLL_REF_BIAS check never fires, and the slowpath that is supposed to take over reference handling is skipped. NVD scores this local with full confidentiality, integrity and availability loss, which is the usual shape of an io_uring reference-handling bug reachable by any local process. On a GPU node this matters because io_uring is available to unprivileged code inside tenant containers unless it has been deliberately restricted, so the boundary being tested is container-to-host, not user-to-user. The record is a stable-tree fix with no exploit detail, so treat the severity as the kernel maintainers' rating rather than a demonstrated escape.

Who can reach it

Local, unauthenticated beyond having code execution on the node: any process that can issue io_uring polled operations, which includes workloads in an ordinary tenant container unless io_uring has been blocked by seccomp policy or the io_uring_disabled sysctl.

What to do

Take the stable kernel that carries the fix commit from your distribution and reboot each node; there is no runtime toggle for this code path. That means draining GPU jobs and rebooting the whole fleet, so most operators will fold it into the next kernel maintenance window. Until then, restricting io_uring for untrusted workloads (seccomp deny of io_uring_setup, or the kernel's io_uring disable knob) removes the reachable path 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.