CVE-2025-22090: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()
If track_pfn_copy() fails, we already added the dst VMA to the maple
tree. As fork() fails, we'll cleanup the maple tree, and stumble over
the dst VMA for which we neither performed any reservation nor copied
any page tables.
Consequently untrack_pfn() will see VM_PAT and try obtaining the
PAT information from the page table -- which fails because the page
table was not copied.
The easiest fix would be to simply clear the VM_PAT flag of the dst VMA
if track_pfn_copy() fails. However, the whole thing is about "simply"
clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()
and performed a reservation, but copying the page tables fails, we'll
simply clear the VM_PAT flag, not properly undoing the reservation ...
which is also wrong.
So let's fix it properly: set the VM_PAT flag only if the reservation
succeeded (leaving it clear initially), and undo the reservation if
anything goes wrong while copying the page tables: clearing the VM_PAT
flag after undoing the reservation.
Note that any copied page table entries will get zapped when the VMA will
get removed later, after copy_page_range() succeeded; as VM_PAT is not set
then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be
happy. Note that leaving these page tables in place without a reservation
is not a problem, as we are aborting fork(); this process will never run.
A reproducer can trigger this usually at the first try:
https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c
WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110
Modules linked in: ...
CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:get_pat_info+0xf6/0x110
...
Call Trace:
<TASK>
...
untrack_pfn+0x52/0x110
unmap_single_vma+0xa6/0xe0
unmap_vmas+0x105/0x1f0
exit_mmap+0xf6/0x460
__mmput+0x4b/0x120
copy_process+0x1bf6/0x2aa0
kernel_clone+0xab/0x440
__do_sys_clone+0x66/0x90
do_syscall_64+0x95/0x180
Likely this case was missed in:
d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")
... and instead of undoing the reservation we simply cleared the VM_PAT flag.
Keep the documentation of these functions in include/linux/pgtable.h,
one place is more than sufficient -- we should clean that up for the other
functions like track_pfn_remap/untrack_pfn separately.
Security readout for executives and security teams
Plain-English summary
A flaw in x86 Linux memory cleanup can leave PAT tracking inconsistent when process creation fails. A local, low-privileged user may trigger the condition. The supplied CVSS score indicates potentially serious integrity and availability impact, but the cited reproducer demonstrates a kernel warning rather than confirmed compromise.
Executive priority
Treat as a high-priority kernel maintenance issue on multi-user, shared-compute, and other x86 hosts allowing untrusted local code. Prioritize confirmed vulnerable builds, but avoid assuming every listed Linux version is affected because the supplied version metadata is ambiguous.
Technical view
During fork(), copy_page_range() can fail after track_pfn_copy() handling leaves the destination VMA's VM_PAT state inconsistent. Cleanup then calls untrack_pfn(), which attempts to obtain PAT information from page tables that were not copied. The fix delays setting VM_PAT until reservation succeeds and rolls back reservations if page-table copying fails.
Likely exposure
Potentially exposed are x86 Linux systems running affected kernels where local processes can reach PAT/PFN-mapped memory and fork. The bundle lists broad version data through 6.15, but lacks sufficient range/status detail to identify exact affected builds. Non-x86 systems are not implicated by the supplied description.
Exploitation context
The bundle marks KEV false, and no cited source reports active exploitation. A public reproducer reportedly triggers the warning reliably, making the bug readily testable. The supplied evidence does not establish privilege escalation, reliable corruption, or weaponized exploitation.
Researcher notes
The root cause is a reservation and VM_PAT lifecycle mismatch during failed fork cleanup. A previous change reportedly cleared VM_PAT without reliably undoing reservations. No CWE is assigned. Researchers should distinguish reproducible warning behavior from demonstrated security impact and assess whether relevant PFN-mapped VMAs are reachable by low-privileged users.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix for CVE-2025-22090.
Map each deployed kernel branch to the cited stable commits or vendor advisories before declaring remediation.
Confirm the updated kernel is active after maintenance.
Until patched, reduce untrusted local execution on affected x86 hosts where operationally feasible.
Review the cited Siemens advisory if Siemens products are within scope.
Validation and detection
Inventory running kernel builds and architectures across Linux systems.
Compare each build with vendor CVE notices and the applicable cited stable commit.
Confirm the fix delays VM_PAT assignment and rolls back reservations after copy failures.
Test only in an isolated environment and verify failed-fork cleanup no longer produces the reported warning.
Record systems whose exact status remains uncertain and obtain vendor confirmation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-22090 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
8Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.