CVE-2026-93217 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/madvise: skip device-private PMDs in cold and pageout walks
madvise_cold_or_pageout_pte_range() takes pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for a device-private PMD. The subsequent !pmd_present() branch has a VM_BUG_ON() asserting migration is the only allowed non-present case; a device-private PMD trips it.
Skip device-private PMDs in that non-present branch and continue to huge_unlock before calling pmd_folio(). Downgrade the check to VM_WARN_ON_ONCE() so an unexpected PMD softleaf logs a warning rather than panicking. Drop the thp_migration_supported() guard: it expands to IS_ENABLED(CONFIG_ARCH_SUPPORTS_PMD_SOFTLEAF), and both pmd_is_migration_entry() and pmd_is_device_private_entry() 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(MADV_COLD)/MADV_PAGEOUT: pmd_trans_huge(*pmd) reads true, then migrate_vma_pages() flips the PMD to a device-private entry before the PMD lock is acquired.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability identified in the memory management subsystem involves an incorrect handling of device-private Page Middle Directory entries during madvise operations for cold pages and pageout walks. The function madvise_cold_or_pageout_pte_range() acquires a lock on huge PMD entries via pmd_trans_huge_lock(). This routine performs a check using pmd_is_huge(), which incorrectly returns true when the entry is actually a device-private PMD rather than a standard transparent huge page. Consequently, the code proceeds to evaluate whether the PMD is present using !pmd_present(). In this non-present branch, there exists a VM_BUG_ON assertion that strictly enforces migration as the only permissible state for non-present entries. Because device-private PMDs are also considered non-present in this context but do not represent migration states, they trigger this assertion, leading to an immediate kernel panic or crash rather than graceful handling of the condition.
This flaw represents a classic case of improper input validation and incorrect assumption about memory entry types within the virtual memory subsystem. The vulnerability stems from conflating different categories of huge page entries without sufficiently distinguishing between standard transparent huge pages intended for migration and device-private mappings associated with hardware accelerators such as GPUs. By failing to exclude device-private PMDs before reaching the assertion logic, the kernel fails to account for valid but non-standard states that are permitted by other parts of the memory management architecture. This oversight results in a denial of service condition where any process capable of triggering this code path can cause system instability or complete failure through a local privilege escalation vector if executed with appropriate permissions.
The operational impact is significant, particularly in environments utilizing High Memory Management HMM-based GPU drivers that race with madvise calls using MADV_COLD or MADV_PAGEOUT flags. The specific trigger scenario involves a timing window where pmd_trans_huge() initially reads true for the PMD entry, but before the PMD lock is acquired by the madvise routine, migrate_vma_pages() modifies the PMD to become a device-private entry. This race condition exposes the underlying logic flaw in the kernel's memory management path. The resulting crash disrupts system availability and can potentially be exploited for local denial of service attacks against multi-tenant systems or cloud infrastructure where such hardware acceleration is common.
To mitigate this vulnerability, developers have implemented several corrective measures within the mm/madvise module. First, device-private PMDs are now explicitly skipped in the non-present branch to prevent them from reaching the restrictive VM_BUG_ON assertion. The code flow continues to huge_unlock before attempting further operations like pmd_folio(), ensuring proper resource management and avoiding invalid memory access patterns. Additionally, the strict VM_BUG_ON check has been downgraded to a VM_WARN_ON_ONCE macro. This change ensures that unexpected PMD softleaf conditions log a warning message for diagnostic purposes rather than causing an immediate kernel panic, thereby improving system resilience against edge cases in complex hardware interaction scenarios.
Furthermore, redundant configuration guards such as thp_migration_supported() have been removed from the code path since both pmd_is_migration_entry() and pmd_is_device_private_entry() already return false when CONFIG_ARCH_SUPPORTS_PMD_SOFTLEAF is not enabled. This simplification reduces complexity and eliminates unnecessary conditional checks that did not contribute to preventing the vulnerability but added maintenance overhead. The fix aligns with industry standards by addressing CWE-20 Improper Input Validation, as it corrects the kernel's failure to properly validate the type of memory mapping before applying state-specific assertions. It also relates to ATT&CK technique T1499 Endpoint Denial of Service via resource exhaustion or instability caused by exploiting system software vulnerabilities. System administrators should apply available kernel updates that include this patch to restore stability in systems utilizing GPU acceleration and advanced memory management features, ensuring that race conditions between user-space madvise calls and hardware-driven page migrations do not lead to catastrophic failures.