GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel hugetlb: use-after-free of the VMA lock when a userfaultfd handler races an mmap

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

Impact

A local process can race hugetlb fault handling against mmap/munmap so that the kernel re-acquires a VMA lock belonging to a VMA that has already been torn down, giving a use-after-free with the usual path to local privilege escalation or a kernel panic. This matters on GPU nodes because huge pages are standard practice for large training and inference jobs, and userfaultfd is reachable by unprivileged processes in default configurations, so the trigger sits inside any tenant container that is not explicitly restricted. On a shared node the realistic outcome is either a crash that takes every co-tenant job on the host with it, or a container escape to host root with access to every GPU on the box.

Who can reach it

Local, authenticated: any user or container process that can call mmap with hugetlb pages and register a userfaultfd region. No special capability is named in the record; seccomp profiles that block userfaultfd remove the trigger.

What to do

Pick up the fixed stable kernel for your series (commits linked in the record) and reboot. That means draining each GPU node and rebooting it - no hot patch is available from the upstream fix, and running jobs will not survive. Where a reboot cycle cannot be scheduled quickly, blocking userfaultfd for untrusted workloads (seccomp, or the unprivileged_userfaultfd sysctl where available) removes the demonstrated trigger.

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.