Database/Kernel, userspace & hypervisor
Linux kernel io_uring: missing work_flags identity types cause bad refcounts and a double free
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
- Linux kernel (net/sched cls_route): Use-after-free in the cls_route filterCVE-2022-2588 · Linux kernel (net/sched cls_route)High
- Xen on AMD-Vi - unity map handling on device reassignment: AMD-Vi unity mappings are not correctly torn down orCVE-2022-26358 · Xen on AMD-Vi - unity map handling on device reassignmentHigh
- Xen on AMD-Vi - unity map handling: Second XSA-400 AMD-Vi unity-map issue. Stale or incorrect IOMMU mappings acrossCVE-2022-26359 · Xen on AMD-Vi - unity map handlingHigh
- Xen on AMD-Vi - unity map handling: Third XSA-400 AMD-Vi issue. Same class - IOMMU mappings that outlive theirCVE-2022-26360 · Xen on AMD-Vi - unity map handlingHigh
- Xen on AMD-Vi - unity map handling: Fourth XSA-400 AMD-Vi issue. Patch the set togetherCVE-2022-26361 · Xen on AMD-Vi - unity map handlingHigh
- Linux kernel (IPsec ESP): Buffer overflow in the IPsec ESP transformation code - local rootCVE-2022-27666 · Linux kernel (IPsec ESP)High
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.