CVE-2026-31397 Overview
A use of NULL folio vulnerability exists in the Linux kernel's memory management subsystem, specifically within the move_pages_huge_pmd() function. This function handles UFFDIO_MOVE operations for both normal Transparent Huge Pages (THPs) and huge zero pages. The vulnerability occurs when processing huge zero pages where src_folio is explicitly set to NULL and used as a sentinel to skip folio operations.
In the huge zero page branch, passing NULL through folio_pfn() and page_to_pfn() produces different behaviors depending on the memory model: with SPARSEMEM_VMEMMAP, it silently produces a bogus Page Frame Number (PFN), installing a PMD pointing to non-existent physical memory; on other memory models, it results in a NULL pointer dereference.
Critical Impact
This vulnerability can lead to memory corruption through bogus PMD installation pointing to non-existent physical memory, NULL pointer dereference crashes, and potential refcount corruption when vm_normal_page_pmd() incorrectly treats the moved huge zero PMD as a normal page.
Affected Products
- Linux Kernel (versions with vulnerable move_pages_huge_pmd() implementation)
- Systems using Transparent Huge Pages (THP) with UFFDIO_MOVE operations
- Systems with SPARSEMEM_VMEMMAP or other memory models
Discovery Timeline
- 2026-04-03 - CVE CVE-2026-31397 published to NVD
- 2026-04-07 - Last updated in NVD database
Technical Details for CVE-2026-31397
Vulnerability Analysis
The vulnerability resides in the kernel's huge memory management code path that handles page migration operations. When move_pages_huge_pmd() processes huge zero pages, it sets src_folio to NULL as a sentinel value to indicate special handling should be applied. However, this NULL value is subsequently passed to folio_mk_pmd(NULL, pgprot), which internally calls folio_pfn() and page_to_pfn() with a NULL argument.
The behavior depends on the kernel's configured memory model:
SPARSEMEM_VMEMMAP configuration: The NULL dereference silently produces an invalid PFN, causing the kernel to install a Page Middle Directory (PMD) entry pointing to non-existent physical memory addresses.
Other memory models: A direct NULL pointer dereference occurs, causing a kernel crash.
A secondary issue exists where the code reconstructs the destination PMD in the huge zero page branch, inadvertently dropping PMD state such as pmd_special() on architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. This causes vm_normal_page_pmd() to misidentify the moved huge zero PMD as a normal page, leading to refcount corruption.
Root Cause
The root cause is improper handling of the NULL sentinel value for src_folio when processing huge zero pages in move_pages_huge_pmd(). The function uses NULL as a special marker to skip folio operations but fails to account for code paths where the NULL value is dereferenced. Additionally, the PMD reconstruction logic does not preserve critical PMD state flags that were established by commit d82d09e48219, which marked PMD mappings of the huge zero folio as special.
Attack Vector
The vulnerability is triggered through the UFFDIO_MOVE ioctl operation when moving huge zero pages. An attacker with local access and the ability to perform userfaultfd operations could potentially exploit this vulnerability to cause:
- Denial of Service: Triggering a kernel NULL pointer dereference crash on non-SPARSEMEM_VMEMMAP systems
- Memory Corruption: On SPARSEMEM_VMEMMAP systems, the bogus PMD installation could lead to memory corruption
- Refcount Corruption: Through the vm_normal_page_pmd() misidentification issue, potentially affecting memory management integrity
The attack requires local access and the ability to use userfaultfd with UFFDIO_MOVE operations on huge zero pages.
Detection Methods for CVE-2026-31397
Indicators of Compromise
- Kernel panic logs indicating NULL pointer dereference in move_pages_huge_pmd() or related mm/huge_memory functions
- System crashes during memory-intensive operations involving Transparent Huge Pages
- Unexpected memory corruption or system instability when userfaultfd operations are performed
- Kernel oops messages referencing folio_pfn(), page_to_pfn(), or PMD manipulation functions
Detection Strategies
- Monitor kernel logs for NULL pointer dereference errors in the memory management subsystem, particularly in functions related to huge page handling
- Implement kernel crash dump analysis to identify crashes originating from move_pages_huge_pmd() or related THP code paths
- Deploy runtime kernel integrity monitoring to detect anomalous PMD entries pointing to invalid physical memory addresses
- Use kernel debugging tools like KASAN (Kernel Address Sanitizer) to detect NULL dereferences during testing
Monitoring Recommendations
- Enable kernel crash reporting and centralized log collection to capture NULL pointer dereference events across the infrastructure
- Monitor for unusual userfaultfd activity, particularly UFFDIO_MOVE operations on systems handling sensitive workloads
- Implement system stability monitoring to detect patterns of crashes that may indicate exploitation attempts
- Review kernel audit logs for processes performing frequent huge page operations
How to Mitigate CVE-2026-31397
Immediate Actions Required
- Apply the available kernel patches from the official Linux kernel stable branches immediately
- Prioritize patching systems that utilize userfaultfd features or run workloads heavily dependent on Transparent Huge Pages
- Consider disabling userfaultfd for unprivileged users via sysctl vm.unprivileged_userfaultfd=0 as a temporary measure
- Monitor affected systems for signs of instability or crashes related to memory management
Patch Information
The Linux kernel maintainers have released patches that address this vulnerability by:
- Using page_folio(src_page) to obtain the valid huge zero folio from the page (obtained from pmd_page()) instead of passing NULL
- Deriving the destination PMD entry from src_pmdval after pmdp_huge_clear_flush() rather than reconstructing it
- Handling PMD metadata consistently with move_huge_pmd() by marking it soft-dirty and clearing uffd-wp
Patches are available through the following kernel commits:
Workarounds
- Disable unprivileged userfaultfd access by setting vm.unprivileged_userfaultfd=0 to limit the attack surface to privileged users only
- If feasible, disable Transparent Huge Pages temporarily using echo never > /sys/kernel/mm/transparent_hugepage/enabled (note: this may impact performance)
- Restrict access to sensitive systems until patches can be applied
- Implement application-level controls to limit userfaultfd usage where possible
# Configuration example
# Disable unprivileged userfaultfd access (temporary mitigation)
echo 0 > /proc/sys/vm/unprivileged_userfaultfd
# To make persistent across reboots, add to /etc/sysctl.conf:
# vm.unprivileged_userfaultfd = 0
# Optionally disable Transparent Huge Pages (may impact performance)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
