GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF task_vma iterator: mm_struct used without a reference, freed under the iterator

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

Impact

The open-coded task_vma iterator read task->mm locklessly and took mmap_read_trylock() but never called mmget(). If the target task exits during iteration the mm_struct is freed - it is not SLAB_TYPESAFE_BY_RCU - and the iterator keeps using it, a use-after-free on a core memory-management structure. task_vma iteration is what profilers and continuous-profiling agents do constantly on busy GPU nodes, and short-lived training and inference processes exiting mid-scan is the normal state of such a node, not an edge case. The fix takes a real mm reference via a trylock on alloc_lock, releases it with mmput_async(), and additionally rejects irqs-disabled and NMI contexts, since the unlock and mmput paths take spinlocks and could otherwise deadlock from a tracepoint.

Who can reach it

Local. Requires loading a BPF program using the open-coded task_vma iterator - CAP_BPF/CAP_SYS_ADMIN, so profiling and observability agents. Triggering it needs a task to exit concurrently, which is trivially arranged on a shared node.

What to do

Update to a fixed stable or distribution kernel and reboot. Red Hat tracks it for RHEL 6 through 10. If you run a continuous profiler that walks task VMAs, that agent is the thing provoking this, so until the kernel is patched the lowest-cost reduction is pausing or scoping that profiler rather than leaving it sweeping every exiting process.

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.