GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring: missing work_flags identity types cause bad refcounts and a double free

CVSS 7.8CVE-2022-2327Kernel, userspace & hypervisorcurated

Impact

io_uring copies parts of the submitting process's identity (creds, files, fs context) into async work based on per-operation work_flags. Several operations declare an incomplete set, so the identity reference counts go wrong and the same object can be freed twice. On a GPU node this is a local privilege escalation path: any tenant with shell or code execution inside a container that is allowed io_uring syscalls can attack the host kernel, and a host-kernel compromise on a shared GPU node reaches every other tenant's pods and the device files they hold. There is no remote exposure, but GPU nodes are exactly the machines where untrusted tenant code runs locally by design.

Who can reach it

Local, authenticated: any user or container process on the node that can issue io_uring submissions. No special privilege or device access is needed beyond the io_uring syscalls, which are reachable from a default container unless seccomp blocks them.

What to do

Run a kernel that includes commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 (backported to 5.10.y and later stable series) or a distribution kernel carrying it; NetApp has published tracking for its HCI node firmware. Applying it means drain and reboot each node, which on a GPU fleet is a full maintenance window per node unless a live-patch stream carries the fix. As an interim mitigation, block the io_uring syscalls in the container seccomp profile for tenant workloads that do not need them.

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.