CVE-2026-93218: mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd
In the Linux kernel, the following vulnerability has been resolved:
mm/hugememory: skip device-private PMDs in madvisefreehugepmd
madvisefreepterange() checks pmdtranshuge(pmd) unlocked, then madvisefreehugepmd() takes pmdtranshugelock(). pmdishuge() returns true for a device-private PMD, so origpmd can be device-private and enter the !pmdpresent() branch.
Skip device-private PMDs in that non-present branch and continue to out before calling pmdfolio(). Downgrade the check to VMWARNONONCE() so an unexpected PMD softleaf logs a warning rather than panicking. Drop the thpmigrationsupported() guard: it expands to ISENABLED(CONFIGARCHSUPPORTSPMDSOFTLEAF), and both pmdismigrationentry() and pmdisdeviceprivateentry() already return false when that config is not selected, so the guard suppresses only the case where the warning would already be silent.
Potential trigger: an HMM-based GPU driver races with madvise(MADVFREE): migratevmapages() flips the PMD to a device-private entry between the caller's pmdtranshuge() check and the callee's pmdtranshugelock().
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger this issue?
An HMM-based GPU driver must race with madvise(MADV_FREE). Specifically, migrate_vma_pages() must change a PMD to a device-private entry after madvise_free_pte_range() checks pmd_trans_huge() and before madvise_free_huge_pmd() acquires the PMD lock.
Which systems are most likely exposed?
Systems using an HMM-based GPU driver and workloads that invoke madvise(MADV_FREE) are the relevant exposure set. The problematic state involves device-private PMD entries during huge-page handling.
What happens if an unexpected PMD softleaf is encountered after the fix?
The check is downgraded to VM_WARN_ON_ONCE(), so the kernel logs a warning rather than panicking. Device-private PMDs in the non-present path are skipped before pmd_folio() is called.