cve/published/2024/CVE-2024-35877.mbox

From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: CVE-2024-35877: x86/mm/pat: fix VM_PAT handling in COW mappings

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

In the Linux kernel, the following vulnerability has been resolved:

x86/mm/pat: fix VM_PAT handling in COW mappings

PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios.  Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.

Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().

In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.

To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
if we run into that.

We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode.  We'll have to fail fork()->track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.

For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.

Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():

<--- C reproducer --->
 #include <stdio.h>
 #include <sys/mman.h>
 #include <unistd.h>
 #include <liburing.h>

 int main(void)
 {
         struct io_uring_params p = {};
         int ring_fd;
         size_t size;
         char *map;

         ring_fd = io_uring_setup(1, &p);
         if (ring_fd < 0) {
                 perror("io_uring_setup");
                 return 1;
         }
         size = p.sq_off.array + p.sq_entries * sizeof(unsigned);

         /* Map the submission queue ring MAP_PRIVATE */
         map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                    ring_fd, IORING_OFF_SQ_RING);
         if (map == MAP_FAILED) {
                 perror("mmap");
                 return 1;
         }

         /* We have at least one page. Let's COW it. */
         *map = 0;
         pause();
         return 0;
 }
<--- C reproducer --->

On a system with 16 GiB RAM and swap configured:
 # ./iouring &
 # memhog 16G
 # killall iouring
[  301.552930] ------------[ cut here ]------------
[  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
[  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
[  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
[  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
[  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
[  301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
[  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
[  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
[  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
[  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
[  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
[  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
[  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
[  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
[  301.565725] PKRU: 55555554
[  301.565944] Call Trace:
[  301.566148]  <TASK>
[  301.566325]  ? untrack_pfn+0xf4/0x100
[  301.566618]  ? __warn+0x81/0x130
[  301.566876]  ? untrack_pfn+0xf4/0x100
[  301.567163]  ? report_bug+0x171/0x1a0
[  301.567466]  ? handle_bug+0x3c/0x80
[  301.567743]  ? exc_invalid_op+0x17/0x70
[  301.568038]  ? asm_exc_invalid_op+0x1a/0x20
[  301.568363]  ? untrack_pfn+0xf4/0x100
[  301.568660]  ? untrack_pfn+0x65/0x100
[  301.568947]  unmap_single_vma+0xa6/0xe0
[  301.569247]  unmap_vmas+0xb5/0x190
[  301.569532]  exit_mmap+0xec/0x340
[  301.569801]  __mmput+0x3e/0x130
[  301.570051]  do_exit+0x305/0xaf0
...

The Linux kernel CVE team has assigned CVE-2024-35877 to this issue.


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

	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 4.19.312 with commit f18681daaec9665a15c5e7e0f591aad5d0ac622b
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 5.4.274 with commit 09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 5.10.215 with commit c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 5.15.155 with commit 7cfee26d1950250b14c5cb0a37b142f3fcc6396a
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 6.1.85 with commit 97e93367e82752e475a33839a80b33bdbef1209f
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 6.6.26 with commit 51b7841f3fe84606ec0bd8da859d22e05e5419ec
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 6.8.5 with commit 1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
	Issue introduced in 2.6.29 with commit 5899329b19100c0b82dc78e9b21ed8b920c9ffb3 and fixed in 6.9 with commit 04c35ab3bdae7fefbd7c7a7355f29fa03a035221

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-2024-35877
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
	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/f18681daaec9665a15c5e7e0f591aad5d0ac622b
	https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
	https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
	https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a
	https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f
	https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec
	https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
	https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221