GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/mempolicy: device-private PMD from GPU THP migration decoded as a PFN, yielding a bogus folio

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

Impact

Since device-private THP support landed, a PMD can hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory. pmd_trans_huge_lock() accepts any non-present, non-none huge PMD, so queue_folios_pmd() hands that softleaf encoding to pmd_folio(), which treats it as a hardware PFN and returns a bogus folio pointer. Per the patch series cover letter the outcomes range from a VM_BUG_ON on debug kernels to an oops on a bad vmemmap dereference to silently isolating an unrelated live folio from the LRU. The trigger is ordinary NUMA policy work - mbind(), migrate_pages() or set_mempolicy_home_node() - on a range whose THP the GPU driver has moved to device memory, which is exactly the combination a NUMA-tuned GPU node produces.

Who can reach it

Local, unprivileged. A process on a node with an HMM-based GPU driver that migrates an anonymous THP to device memory, then calls mbind(), migrate_pages() or set_mempolicy_home_node() over that range.

What to do

Update to a stable kernel carrying commit 2858b4027f49 or 3d927093b2ad and reboot affected GPU nodes. Only the first of a three-patch series is covered by this id; make sure the backport you take includes the rest of the device-private PMD walk-callback series.

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.