CVE-2025-22090 in Linux
Summary
by MITRE • 04/16/2025
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-22090 resides within the Linux kernel's x86 memory management subsystem, specifically in how the kernel handles page attribute table (PAT) flags during process forking operations. This flaw manifests when the copy_page_range() function fails during a fork() operation, leading to improper handling of VM_PAT flags in virtual memory areas. The issue stems from the kernel's attempt to manage memory type attributes for pages, which are crucial for performance optimization through hardware features like PAT. When a fork() operation fails, the kernel must properly clean up resources, but the existing code path does not correctly handle cleanup of PAT-related state, resulting in a kernel panic.
The technical root cause involves the interaction between several kernel functions including track_pfn_copy(), untrack_pfn(), and copy_page_range(). During the execution of copy_page_range(), if track_pfn_copy() fails, the kernel has already added the destination VMA to the maple tree data structure but has not yet performed proper reservation or page table copying. When fork() fails, the cleanup process attempts to iterate through the maple tree and encounters a VMA with VM_PAT set, but the page tables have not been copied, causing untrack_pfn() to attempt to retrieve PAT information from non-existent page table entries. This leads to a kernel panic at the get_pat_info() function, as referenced in the stack trace showing the failure at arch/x86/mm/pat/memtype.c:983. The problem is categorized under CWE-248 (Uncaught Exception) and relates to improper resource management in kernel space.
The operational impact of this vulnerability is significant as it can cause system crashes and potential denial of service conditions when processes attempt to fork under certain memory management conditions. The vulnerability affects systems running Linux kernel versions where the problematic code path exists, particularly those utilizing x86 architectures with PAT support. Attackers could potentially exploit this by creating specific memory allocation patterns that trigger the fork() failure scenario, leading to system instability. The vulnerability is classified under the ATT&CK technique T1499.004 (Endpoint Denial of Service) and could be leveraged in privilege escalation scenarios if combined with other kernel vulnerabilities. The reproducer provided demonstrates the issue occurs consistently on the first attempt, indicating this is not a race condition but a deterministic flaw in the resource management logic.
The fix implemented addresses the fundamental issue by changing the logic flow for setting and clearing VM_PAT flags. Instead of simply clearing the VM_PAT flag when track_pfn_copy() fails, the solution ensures that VM_PAT is only set if the reservation succeeds, and proper cleanup is performed if any subsequent operations fail. This approach prevents the inconsistent state that led to the kernel panic by ensuring proper resource management throughout the entire operation lifecycle. The fix also ensures that if page table copying fails after a successful reservation, the reservation is properly undone before clearing the VM_PAT flag. This solution prevents both the immediate crash scenario and potential memory management inconsistencies that could occur if reservations were not properly undone. The implementation follows established kernel development practices for resource management and aligns with the principle of least privilege and proper error handling in kernel space operations. The solution also addresses documentation inconsistencies in include/linux/pgtable.h by ensuring function documentation is centralized and consistent across related functions, which helps prevent similar issues in the future.