CVE-2026-89758: mm/mempolicy: skip non-present PMDs when queueing folios
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: skip non-present PMDs when queueing folios
Patch series "mm: handle device-private PMDs in walk callbacks", v3.
Since commit 368076f52ebe ("mm/hugememory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migratevmapages().
pmdtranshugelock() succeeds for such PMDs (pmdishuge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VMBUGON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.
This patch (of 3):
queuefoliospmd() is called under pmdtranshugelock(), whose pmdishuge() check returns true for any non-present, non-none PMD softleaf. Passing such a PMD to pmdfolio() treats the softleaf encoding as a hardware PFN and can return a bogus folio pointer.
Mirror queuefoliospterange(): handle non-present entries before looking up a folio. Keep migration entries counted as failures, but skip other non-present PMDs such as device-private entries.
Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migratevmapages(), leaving a device-private PMD. Userspace then calls mbind(), migratepages() or setmempolicyhomenode() on that range.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected path is reachable when an HMM-based GPU driver migrates an anonymous THP folio to device memory using migrate_vma_pages(), leaving a device-private swap entry in a PMD. Systems without that device-private PMD scenario are not identified as affected by the provided data.
What impact can occur when the affected path is reached?
Outcomes include a VM_BUG_ON() on debug kernels, an oops caused by a bogus vmemmap dereference, or silent isolation of an unrelated live folio from the LRU in an aliasing case. The issue arises when a non-present huge PMD is passed to pmd_folio(), which can produce a bogus folio pointer.
Is a default Linux configuration known to be affected?
The provided information does not state whether the required HMM-based GPU driver, anonymous THP use, and migration to device memory are enabled in default configurations. Exposure depends on whether those conditions can occur on the system.