GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/vmalloc: use-after-free when vmap huge-page promotion frees a page table under a concurrent ptdump walk

CVE-2026-74672Kernel, userspace & hypervisorcurated

Impact

vmap promotes kernel page tables to huge leaf entries and frees the lower-level table with no lock held against a concurrent ptdump walker, so ptdump can dereference a freed page table. That is a kernel use-after-free on core memory-management structures, which is the class of bug that turns into arbitrary kernel memory corruption rather than a clean crash. The practical reachability is narrow: walk_page_range_debug() has exactly one user, ptdump, which is a debug facility exposed through debugfs and normally not readable by tenants on a production GPU node. On hosts where the kernel debug page-table dump is not enabled or not exposed, there is no way to drive the race.

Who can reach it

Local, and requires the ability to trigger a ptdump page-table walk concurrently with vmalloc huge-mapping activity - in practice root or a user with access to the kernel debugfs ptdump interface. Not reachable from an unprivileged GPU pod on a hardened node with debugfs unmounted or restricted.

What to do

Apply the stable-series fix; the change makes vmap huge promotion take the init_mm mmap read lock across the entry install and the page-table free, and carries a partial revert of the earlier arm64-specific mitigation (commit fa93b45fd397) to avoid a deadlock, so take the full backported series rather than cherry-picking one commit. Deployment is a kernel update and reboot per node, requiring a drain of GPU workloads. Until then, keeping debugfs unmounted or restricted on production nodes removes the only in-tree 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.