cbcvebase.
CVE-2025-39844
published 2025-09-19

CVE-2025-39844: In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we…

medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level pa

Affected

25 ranges
VendorProductVersion rangeFixed in
debiandebian_linux
debianlinux< linux 6.1.153-1 (bookworm)linux 6.1.153-1 (bookworm)
debianlinux-6.1< linux 6.1.153-1 (bookworm)linux 6.1.153-1 (bookworm)
linuxlinux
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < 732e62212f49d549c91071b4da7942ee3058f7a2732e62212f49d549c91071b4da7942ee3058f7a2
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < eceb44e1f94bd641b2a4e8c09b64c797c4eabc15eceb44e1f94bd641b2a4e8c09b64c797c4eabc15
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < 6797a8b3f71b2cb558b8771a03450dc3e004e4536797a8b3f71b2cb558b8771a03450dc3e004e453
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < 4f7537772011fad832f83d6848f8eab282545bef4f7537772011fad832f83d6848f8eab282545bef
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < 469f9d22751472b81eaaf8a27fcdb5a70741c342469f9d22751472b81eaaf8a27fcdb5a70741c342
linuxlinux>= 8d400913c231bd1da74067255816453f96cd35b0 < 7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.1.153-16.1.153-1
linuxlinux_kernel>= 0 < 6.12.48-16.12.48-1
linuxlinux_kernel>= 0 < 6.16.6-16.16.6-1
linuxlinux_kernel>= 0 < 5.15.0-163.1735.15.0-163.173
linuxlinux_kernel>= 0 < 6.8.0-106.1066.8.0-106.106
linuxlinux_kernel>= 5.13 < 5.15.1925.15.192
linuxlinux_kernel>= 5.16 < 6.1.1516.1.151
linuxlinux_kernel>= 6.13 < 6.16.66.16.6
linuxlinux_kernel>= 6.2 < 6.6.1056.6.105
linuxlinux_kernel>= 6.7 < 6.12.466.12.46
msrcazl3_kernel_6.6.104.2-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-2_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0
ubuntulinux-xilinx

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM