linux-cve-announce - CVE-2025-22090: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025041617-CVE-2025-22090-f2fa@gregkh>
Date: Wed, 16 Apr 2025 16:13:01 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2025-22090: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2025-22090 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.29 with commit 2ab640379a0ab4cef746ced1d7e04a0941774bcb and fixed in 6.6.87 with commit b07398e8a5da517083f5c3f2daa8f6681b48ab28
	Issue introduced in 2.6.29 with commit 2ab640379a0ab4cef746ced1d7e04a0941774bcb and fixed in 6.12.23 with commit 8d6373f83f367dbed316ddeb178130a3a64b5b67
	Issue introduced in 2.6.29 with commit 2ab640379a0ab4cef746ced1d7e04a0941774bcb and fixed in 6.13.11 with commit da381c33f3aa6406406c9fdf07b8b0b63e0ce722
	Issue introduced in 2.6.29 with commit 2ab640379a0ab4cef746ced1d7e04a0941774bcb and fixed in 6.14.2 with commit de6185b8892d88142ef69768fe4077cbf40109c0
	Issue introduced in 2.6.29 with commit 2ab640379a0ab4cef746ced1d7e04a0941774bcb and fixed in 6.15-rc1 with commit dc84bc2aba85a1508f04a936f9f9a15f64ebfb31

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-22090
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/x86/mm/pat/memtype.c
	include/linux/pgtable.h
	kernel/fork.c
	mm/memory.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/b07398e8a5da517083f5c3f2daa8f6681b48ab28
	https://git.kernel.org/stable/c/8d6373f83f367dbed316ddeb178130a3a64b5b67
	https://git.kernel.org/stable/c/da381c33f3aa6406406c9fdf07b8b0b63e0ce722
	https://git.kernel.org/stable/c/de6185b8892d88142ef69768fe4077cbf40109c0
	https://git.kernel.org/stable/c/dc84bc2aba85a1508f04a936f9f9a15f64ebfb31