CVE-2026-31397
mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd()
Description
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.
INFO
Published Date :
April 3, 2026, 4:16 p.m.
Last Modified :
July 24, 2026, 10:10 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | HIGH | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
Solution
- Update the Linux kernel to the latest version.
- Apply relevant patches for memory management fixes.
- Review kernel configurations for huge page handling.
- Test system stability after applying updates.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-31397.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-31397 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-31397
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-31397 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-31397 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Jul. 24, 2026
Action Type Old Value New Value Added Translation Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/huge_memory: corrige el uso de folio NULL en move_pages_huge_pmd() move_pages_huge_pmd() maneja UFFDIO_MOVE tanto para THPs normales como para páginas cero enormes. Para la ruta de la página cero enorme, src_folio se establece explícitamente en NULL, y se usa como un centinela para omitir operaciones de folio como lock y rmap. En la rama de la página cero enorme, src_folio es NULL, por lo que folio_mk_pmd(NULL, pgprot) pasa NULL a través de folio_pfn() y page_to_pfn(). Con SPARSEMEM_VMEMMAP esto produce silenciosamente un PFN erróneo, instalando un PMD que apunta a memoria física inexistente. En otros modelos de memoria es una desreferencia NULL. Usar page_folio(src_page) para obtener el folio cero enorme válido de la página, que se obtuvo de pmd_page() y permanece válido en todo momento. Después del commit d82d09e48219 ('mm/huge_memory: marcar las asignaciones PMD del folio cero enorme como especiales'), los PMD cero enormes movidos deben permanecer especiales para que vm_normal_page_pmd() continúe tratándolos como asignaciones especiales. move_pages_huge_pmd() actualmente reconstruye el PMD de destino en la rama de la página cero enorme, lo que elimina el estado del PMD como pmd_special() en arquitecturas con CONFIG_ARCH_HAS_PTE_SPECIAL. Como resultado, vm_normal_page_pmd() puede tratar el PMD cero enorme movido como una página normal y corromper su refcount. En lugar de reconstruir el PMD a partir del folio, derivar la entrada de destino de src_pmdval después de pmdp_huge_clear_flush(), luego manejar los metadatos del PMD de la misma manera que move_huge_pmd() lo hace para las entradas movidas, marcándolo como soft-dirty y borrando uffd-wp. -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 17, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': 'e3981db444a0a18d350d9f92e3f2e8d489b54211', 'lessThan': 'f3caaee0f9e489fd2282d4ce45791dc8aed2da62', 'versionType': 'git'}, {'status': 'affected', 'version': 'e3981db444a0a18d350d9f92e3f2e8d489b54211', 'lessThan': 'e3133d0986dc5a231d5419167dbac65312b28b41', 'versionType': 'git'}, {'status': 'affected', 'version': 'e3981db444a0a18d350d9f92e3f2e8d489b54211', 'lessThan': 'fae654083bfa409bb2244f390232e2be47f05bfc', 'versionType': 'git'}], 'programFiles': ['mm/huge_memory.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.16'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.16', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.18.20', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '6.19.10', 'versionType': 'semver', 'lessThanOrEqual': '6.19.*'}, {'status': 'unaffected', 'version': '7.0', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['mm/huge_memory.c'], 'defaultStatus': 'affected'}] -
Initial Analysis by [email protected]
May. 20, 2026
Action Type Old Value New Value Added CWE CWE-476 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 6.19.10 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.16 up to (excluding) 6.18.20 Added Reference Type kernel.org: https://git.kernel.org/stable/c/e3133d0986dc5a231d5419167dbac65312b28b41 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/f3caaee0f9e489fd2282d4ce45791dc8aed2da62 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/fae654083bfa409bb2244f390232e2be47f05bfc Types: Patch -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Apr. 27, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Apr. 03, 2026
Action Type Old Value New Value Added Description 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. Added Reference https://git.kernel.org/stable/c/e3133d0986dc5a231d5419167dbac65312b28b41 Added Reference https://git.kernel.org/stable/c/f3caaee0f9e489fd2282d4ce45791dc8aed2da62 Added Reference https://git.kernel.org/stable/c/fae654083bfa409bb2244f390232e2be47f05bfc