CVE-2025-39844 — mm: move page table sync declarations to linux/pgtable.h
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: <TASK> __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 ...] </TASK> 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 page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---
Who exploits it and how urgent it is
A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.
How the score was calculated
- EPSS 0.2% (30-day exploitation probability)+1
- Technical severity (medium)+3
The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).
Triage
Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.
Remediation
Fixes and mitigations documented by the sources — linked to the original advisory.
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
First 24 hours
Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.
- Identify exposed assets running the affected vendor/product/version combinations (Debian Debian Linux, Linux Linux, Linux Linux Kernel).
- Apply the fixed version or the patch documented under Remediation.
- Search available logs for exploit probes, errors and authentication anomalies.
Affected scope
Vendor, product and versions as the sources word them.
| Vendor | Product | Versions | Status | Source |
|---|---|---|---|---|
| Debian | Debian Linux | version 11.0 | Vulnerable | NIST National Vulnerability Database |
| Linux | Linux | version 5.13≥ 8d400913c231bd1da74067255816453f96cd35b0 and < 7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d≥ 8d400913c231bd1da74067255816453f96cd35b0 and < 469f9d22751472b81eaaf8a27fcdb5a70741c342≥ 8d400913c231bd1da74067255816453f96cd35b0 and < 4f7537772011fad832f83d6848f8eab282545bef≥ 8d400913c231bd1da74067255816453f96cd35b0 and < 6797a8b3f71b2cb558b8771a03450dc3e004e453≥ 8d400913c231bd1da74067255816453f96cd35b0 and < eceb44e1f94bd641b2a4e8c09b64c797c4eabc15≥ 8d400913c231bd1da74067255816453f96cd35b0 and < 732e62212f49d549c91071b4da7942ee3058f7a2 | Vulnerable | CVE Program (cve.org) e CISA ADP |
| Linux | Linux Kernel |
version 6.17-rc3version 6.17-rc4version 6.17-rc2version 6.17-rc1≥ 6.13 and < 6.16.6≥ 6.7 and < 6.12.46≥ 6.2 and < 6.6.105≥ 5.16 and < 6.1.151 and 1 more≥ 5.13 and < 5.15.192 |
Vulnerable | NIST National Vulnerability Database |
Attack characteristics
The CVSS vector, decoded. It describes the attack, not your exposure to it.
Every base score collected
Sources score independently and may disagree; each row says who scored it and under which version.
| Score | Version | Severity | Expl. | Impact | Scored by |
|---|---|---|---|---|---|
| 5.5 | CVSS 3.1 | Medium | 1.8 | 3.6 | nvd@nist.gov via NIST National Vulnerability Database |
| 5.5 | CVSS 3.1 | Medium | — | — | GitHub, Inc. via GitHub Security Advisories |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (score shown at the top: nvd@nist.gov) Detection
Read off the CVSS vector and the weakness class. Starting points, not tested rules.
- Local/physical vector: focus on endpoint telemetry (EDR) from affected hosts.
Timeline
What happened to this CVE, newest first.
- 2026
- Affected products added · linux/linux
- Record published
- Fix documented
- Affected products added · linux/linux kernel, debian/debian linux
- CVSS changed · 5.5
- Source status changed · → Modified
- Record created in this database
- 2025
- CVE published
Source activity
Repeated readings are counted rather than listed.
- 2× References added · Oct 19, 2026 – Oct 19, 2026
- 1× Official description updated · Oct 19, 2026 – Oct 19, 2026
References
10 on the record
- git.kernel.org/stable/c/6797a8b3f71b2cb558b8771a03450dc3e004e453
- git.kernel.org/stable/c/7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d
- git.kernel.org/stable/c/4f7537772011fad832f83d6848f8eab282545bef
- git.kernel.org/stable/c/eceb44e1f94bd641b2a4e8c09b64c797c4eabc15
- git.kernel.org/stable/c/469f9d22751472b81eaaf8a27fcdb5a70741c342
- git.kernel.org/stable/c/732e62212f49d549c91071b4da7942ee3058f7a2
- github.com/advisories/GHSA-fv7f-vxxp-c378
- nvd.nist.gov/vuln/detail/CVE-2025-39844
- cert-portal.siemens.com/productcert/html/ssa-032379.html
- lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Elsewhere on this site
Related CVEs (same products)
- Unknown CVE-2026-98868 dm-pcache: reject a kset that overruns its segment 1d
- Unknown CVE-2026-98866 sched/cache: Introduce task_struct->sched_cache_grp to fix UAF 1d
- Unknown CVE-2026-98867 dm-pcache: bound the logical key offset from persistent memory 1d
- Unknown CVE-2026-98865 sched_ext: Don't run ops.dequeue() with a DSQ lock held 1d
- Unknown CVE-2026-98864 sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task 1d
- Unknown CVE-2026-98863 KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails 1d
Not in any source we poll
Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.
- No CISA SSVC assessment.
- No CWE classification.
- No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
- No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
- No exploit packet captures, log samples, or incident case IDs supplied.
Answered from this record
Text assembled only from the fields above — no additional claims.
What should defenders know first?
CVE-2025-39844 is "mm: move page table sync declarations to linux/pgtable.h", rated Medium. It affects Debian Linux (Debian); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. CVSS 5.5 describes technical severity. EPSS 0.15% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.
Comments
Moderated technical discussion. Read the community guidelines.
No comments yet.
Sign in or create an account to comment and suggest corrections.