CVE-2026-31456

What it actually does

This is a Linux kernel memory-management race condition in the page table walking code. A concurrent split of a PUD-sized mapping and a refault of the same PUD leaf entry can cause the kernel to descend into a PMD range that is no longer valid. Under the right timing, this results in a kernel page fault and BUG/Oops in page-walking paths such as walk_pgd_range(), __walk_page_range(), walk_page_vma(), and show_numa_map(). The practical technical impact is local denial of service through a kernel crash or system instability; the published CVSS vector indicates local access, low privileges, high attack complexity, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, interrupting workloads, virtualized infrastructure, GPU/VFIO passthrough hosts, or systems where processes interact with large memory mappings and NUMA reporting. Because exploitation requires local low-privileged access and precise race timing, broad internet-scale exploitation is unlikely; however, multi-user servers, shared compute platforms, virtualization hosts, and environments running untrusted local workloads have higher operational exposure. The vulnerability is not listed in CISA KEV, has no known ransomware association, no known public exploit maturity, and has a very low, flat EPSS score, so remediation should be prioritized based on system criticality and local-user exposure rather than emergency internet-facing risk.

How an attack unfolds

An attacker first needs the ability to run code or trigger reads as a local low-privileged user on an affected Linux system. They then attempt to create timing conditions where one thread is walking a process address space, for example by repeatedly reading /proc/<pid>/numa_maps, while another thread or subsystem causes concurrent changes to large page table entries, such as refaulting or splitting a PUD leaf mapping. The published reproducer context involves reading numa_maps while VFIO-PCI is setting up DMA through vfio_pin_pages_remote on a large BAR mapping. If the race is won, the kernel may attempt to walk a PMD range that has disappeared, triggering an invalid memory access in page-walking code and producing a kernel Oops or BUG. The expected attacker outcome is a denial-of-service crash or forced reboot, not privilege escalation or data theft based on the provided impact vector.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the mm/pagewalk race, specifically the change that validates the PUD entry in walk_pmd_range() using a stable pudp_get() snapshot and retries with ACTION_AGAIN when the PUD is not present or is a leaf. No exact fixed package versions were provided in the input, so use your Linux distribution vendor's security advisories and kernel changelogs to identify the corrected kernel for your release stream. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, reducing access to VFIO device passthrough capabilities, and applying least privilege to users and services that can interact with /proc process memory-map interfaces. For highly available systems, schedule kernel updates with reboot planning because kernel remediation generally requires booting into the patched kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build that includes the mm/pagewalk fix for this issue, not merely that the package is installed on disk. Validate with uname -r, package-manager kernel version checks, and vendor advisory mapping for the deployed distribution. After updating, reboot into the patched kernel and verify that the vulnerable code path no longer crashes under regression testing that exercises concurrent /proc/<pid>/numa_maps reads and large mapping or VFIO-related activity. Review kernel logs after testing for absence of Oops/BUG traces referencing walk_pgd_range, walk_pmd_range, __walk_page_range, walk_page_vma, or show_numa_map. In fleet scanning, flag systems running affected kernel builds, especially those that allow local untrusted users, containers with elevated host access, or VFIO-PCI passthrough workloads.

Typical attack path

1. Gain local code execution or shell access on an affected Linux host as a low-privileged user.
2. Identify a target process or workload with large mappings or conditions that exercise PUD/PMD page-table walking, such as VFIO-PCI DMA setup with large BAR mappings.
3. Repeatedly trigger page-table walking paths, such as reading /proc/<pid>/numa_maps for the target process.
4. Concurrently trigger mapping changes, refaults, or page-table splits that race with the page walker.
5. Win the race so the kernel descends into an invalid PMD range after the PUD state changed.
6. Cause a kernel BUG/Oops and degrade availability through a crash, hang, or required reboot.

How to detect it

Look for evidence of kernel crashes or instability rather than network indicators. Primary sources are kernel ring buffer logs, system journal entries, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, hypervisor console logs, and monitoring alerts for unexpected reboots. Search for Oops or BUG traces that include page-walking functions such as walk_pgd_range, walk_pmd_range, __walk_page_range, walk_page_vma, and show_numa_map. Correlate these events with local process activity involving reads of /proc/<pid>/numa_maps and workloads using VFIO-PCI passthrough, large BAR mappings, or DMA setup. If auditd, eBPF telemetry, or EDR process monitoring is available, review repeated or high-frequency access to /proc/*/numa_maps shortly before the crash. Absence of these artifacts does not prove non-exploitation because a full system crash can truncate logs; persistent crash dumps and remote log forwarding improve confidence.

• BUG: unable to handle page fault for address:
• Oops: Oops: 0000
• RIP: 0010:walk_pgd_range
• __walk_page_range+
• walk_page_vma+
• show_numa_map+
• seq_read_iter+
• vfio_pin_pages_remote
• vfio-pci
• /proc/*/numa_maps
• walk_pmd_range
• ACTION_AGAIN
• PGD 0 P4D 0

What your security team should do

• Prioritize patching shared Linux systems, virtualization hosts, GPU/VFIO passthrough hosts, high-availability servers, and platforms that run untrusted local workloads.
• Track the relevant Linux distribution advisory and deploy the first vendor kernel that includes the mm/pagewalk PUD validation fix; reboot systems into the patched kernel.
• Harden local access while patching is pending: remove unnecessary shell accounts, restrict sudo pathways, and limit who can run workloads on affected hosts.
• Restrict VFIO-PCI passthrough and similar device/DMA setup capabilities to trusted administrators or trusted workloads only.
• Monitor kernel logs for Oops/BUG signatures in page-walking paths and correlate with local user activity and reads of /proc/<pid>/numa_maps.
• Because EPSS is very low, KEV status is false, and exploit maturity is none, handle this as a local availability-risk patch rather than an internet-facing emergency, unless the affected host supports untrusted multi-tenant workloads.
• Include this vulnerability in kernel lifecycle management checks to ensure installed, running, and fallback boot kernels are all remediated or controlled.