CVE Catalog

CVE-2026-31397

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.12%

2th percentile - higher than 2% of all known CVEs

Summary

In the Linux kernel, a vulnerability in move_pages_huge_pmd() handling UFFDIO_MOVE for THP and huge zero pages was found. For zero pages, src_folio is set to NULL, causing folio_mk_pmd(NULL) to create a PMD pointing to non-existent physical memory (SPARSEMEM_VMEMMAP) or a NULL dereference (other models). Additionally, PMD reconstruction in the zero branch drops pmd_special(), allowing vm_normal_page_pmd() to treat the moved zero page as normal and corrupt its refcount.

Risk Assessment

An attacker could exploit this to cause a system crash (NULL dereference) or potentially escalate privileges by corrupting memory structures, threatening data confidentiality and integrity.

Recommendation

Immediately update the Linux kernel to a version containing the fix (commit d82d09e48219 and related). For production systems, apply the security patch from your distributor.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd() move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge zero pages. For the huge zero page path, src_folio is explicitly set to NULL, and is used as a sentinel to skip folio operations like lock and rmap. In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL, pgprot) passes NULL through folio_pfn() and page_to_pfn(). With SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD pointing to non-existent physical memory. On other memory models it is a NULL dereference. Use page_folio(src_page) to obtain the valid huge zero folio from the page, which was obtained from pmd_page() and remains valid throughout. After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge zero folio special"), moved huge zero PMDs must remain special so vm_normal_page_pmd() continues to treat them as special mappings. move_pages_huge_pmd() currently reconstructs the destination PMD in the huge zero page branch, which drops PMD state such as pmd_special() on architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result, vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page and corrupt its refcount. Instead of reconstructing the PMD from the folio, derive the destination entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD metadata the same way move_huge_pmd() does for moved entries by marking it soft-dirty and clearing uffd-wp.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS