CVE-2026-31456: mm/pagewalk: fix race between concurrent split and refault

Q: What conditions can trigger this issue in practice?

The reported reproduction involves reading a process's numa_maps while VFIO-PCI concurrently sets up DMA for that process through vfio_pin_pages_remote on a large BAR. The race occurs when a PUD entry is split while another thread refaults the PUD leaf entry.

Q: What is the likely impact if the race is triggered?

The race can cause page-walk code to access a PMD range that has disappeared, leading to a kernel BUG and an unable-to-handle-page-fault Oops. The CVSS vector indicates local access, low privileges, high attack complexity, and availability impact only.

Q: How can an administrator identify a possible occurrence?

Look for kernel logs reporting a BUG or Oops during page walking, including an "unable to handle page fault" message and a stack location involving walk_pgd_range. The example log also includes VFIO-PCI activity while enabling a device.

Published Apr 22, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

mm/pagewalk: fix race between concurrent split and refault

The splitting of a PUD entry in walkpudrange() can race with a concurrent thread refaulting the PUD leaf entry causing it to try walking a PMD range that has disappeared.

An example and reproduction of this is to try reading numamaps of a process while VFIO-PCI is setting up DMA (specifically the vfiopinpagesremote call) on a large BAR for that process.

This will trigger a kernel BUG: vfio-pci 0000:03:00.0: enabling device (0000 -> 0002) BUG: unable to handle page fault for address: ffffa23980000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI ... RIP: 0010:walkpgdrange+0x3b5/0x7a0 Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 <49> f7 06 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74 RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287 RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0 RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000 R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000 R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000 FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> walkpagerange+0x195/0x1b0 walkpagevma+0x62/0xc0 shownumamap+0x12b/0x3b0 seqreaditer+0x297/0x440 seqread+0x11d/0x140 vfsread+0xc2/0x340 ksysread+0x5f/0xe0 dosyscall64+0x68/0x130 ? getpagefromfreelist+0x5c2/0x17e0 ? masstoreprealloc+0x17e/0x360 ? vmasetpageprot+0x4c/0xa0 ? allocpagesnoprof+0x14e/0x2d0 ? modmemcglruvecstate+0x8d/0x140 ? lruvecstatmodfolio+0x76/0xb0 ? foliomodstat+0x26/0x80 ? doanonymouspage+0x705/0x900 ? handlemmfault+0xa8d/0x1000 ? countmemcgevents+0x53/0xf0 ? handlemmfault+0xa5/0x360 ? douseraddrfault+0x342/0x640 ? archexittousermodeprepare.constprop.0+0x16/0xa0 ? irqentryexittousermode+0x24/0x100 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fe88464f47e Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003 RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000 R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 </TASK>

Fix this by validating the PUD entry in walkpmdrange() using a stable snapshot (pudpget()). If the PUD is not present or is a leaf, retry the walk via ACTIONAGAIN instead of descending further. This mirrors the retry logic in walkpterange(), which lets walkpmdrange() retry if the PTE is not being got by pteoffsetmaplock().

Affected Software

8 affected components

Linux Linux kernel

Linux Linux kernel>=6.12<6.18.21

Linux Linux kernel>=6.19<6.19.11

Linux Linux kernel=7.0-rc1

Linux Linux kernel=7.0-rc2

Linux Linux kernel=7.0-rc3

Linux Linux kernel=7.0-rc4

Linux Linux kernel=7.0-rc5

Event History

Apr 22, 2026

CVE Published

via MITRE·01:53 PM

Data Sourced

via MITRE·01:53 PM

Description

Data Sourced

via NVD·02:16 PM

RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

What conditions can trigger this issue in practice?

The reported reproduction involves reading a process's numa_maps while VFIO-PCI concurrently sets up DMA for that process through vfio_pin_pages_remote on a large BAR. The race occurs when a PUD entry is split while another thread refaults the PUD leaf entry.

What is the likely impact if the race is triggered?

The race can cause page-walk code to access a PMD range that has disappeared, leading to a kernel BUG and an unable-to-handle-page-fault Oops. The CVSS vector indicates local access, low privileges, high attack complexity, and availability impact only.

How can an administrator identify a possible occurrence?

Look for kernel logs reporting a BUG or Oops during page walking, including an "unable to handle page fault" message and a stack location involving walk_pgd_range. The example log also includes VFIO-PCI activity while enabling a device.

CVE-2026-31456: mm/pagewalk: fix race between concurrent split and refault

Affected Software

Event History

Frequently Asked Questions

What conditions can trigger this issue in practice?

What is the likely impact if the race is triggered?

How can an administrator identify a possible occurrence?

Company

Resources

Contact

Frequently Asked Questions

What conditions can trigger this issue in practice?

What is the likely impact if the race is triggered?

How can an administrator identify a possible occurrence?