GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/rmap: missing barrier lets a reused anon_vma hang tasks and use-after-free its root

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

Impact

__anon_vma_prepare() published a freshly allocated anon_vma to vma->anon_vma with a plain store, so on a weakly ordered architecture a second thread could find the anon_vma while still seeing the old root pointer. It then locks one root and unlocks another, leaving an anon_vma locked forever - the reporters saw hung-task splats on an arm64 server with anon_vma->root->rwsem permanently held, plus a use-after-free of anon_vma->root. For an operator the visible failure is processes wedged in page-fault paths that no signal clears, which on a GPU node means a job that holds its allocations while making no progress and a node that only a reboot recovers. Requires two adjacent anon_vma-compatible but unmerged VMAs faulted concurrently; this is a core memory-management path, not GPU-specific, and arm64 hosts are the reported case.

Who can reach it

Local unprivileged process on the host (or inside a container) that can mprotect adjacent mappings and fault them from two threads. No authentication beyond code execution; triggering is a race.

What to do

Upgrade to a stable kernel with the barrier fix for your series (five stable commits listed) and reboot the node; there is no runtime mitigation for a memory-ordering bug in the fault path. Prioritize arm64 hosts, where the reordering is observable. No distro fixed versions appear in the record.

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.