UBUNTU-CVE-2024-46787
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
02 / AFFECTED SOFTWARE
Affected packages
17 explicit affected versions
14 explicit affected versions
8 explicit affected versions
33 explicit affected versions
5 explicit affected versions
8 explicit affected versions
1 explicit affected versions
10 explicit affected versions
111 explicit affected versions
1 explicit affected versions
13 explicit affected versions
26 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
1 explicit affected versions
1 explicit affected versions
12 explicit affected versions
2 explicit affected versions
139 explicit affected versions
10 explicit affected versions
11 explicit affected versions
13 explicit affected versions
11 explicit affected versions
10 explicit affected versions
7 explicit affected versions
61 explicit affected versions
10 explicit affected versions
6 explicit affected versions
12 explicit affected versions
40 explicit affected versions
106 explicit affected versions
66 explicit affected versions
50 explicit affected versions
19 explicit affected versions
6 explicit affected versions
76 explicit affected versions
14 explicit affected versions
61 explicit affected versions
78 explicit affected versions
69 explicit affected versions
56 explicit affected versions
10 explicit affected versions
8 explicit affected versions
14 explicit affected versions
68 explicit affected versions
7 explicit affected versions
67 explicit affected versions
9 explicit affected versions
13 explicit affected versions
73 explicit affected versions
11 explicit affected versions
35 explicit affected versions
28 explicit affected versions
26 explicit affected versions
18 explicit affected versions
27 explicit affected versions
104 explicit affected versions
64 explicit affected versions
14 explicit affected versions
108 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
109 explicit affected versions
18 explicit affected versions
62 explicit affected versions
16 explicit affected versions
7 explicit affected versions
12 explicit affected versions
12 explicit affected versions
12 explicit affected versions
14 explicit affected versions
1 explicit affected versions
7 explicit affected versions
95 explicit affected versions
94 explicit affected versions
12 explicit affected versions
9 explicit affected versions
108 explicit affected versions
22 explicit affected versions
9 explicit affected versions
1 explicit affected versions
10 explicit affected versions
176 explicit affected versions
37 explicit affected versions
43 explicit affected versions
1 explicit affected versions
26 explicit affected versions
13 explicit affected versions
15 explicit affected versions
9 explicit affected versions
29 explicit affected versions
98 explicit affected versions
13 explicit affected versions
73 explicit affected versions
8 explicit affected versions
89 explicit affected versions
68 explicit affected versions
31 explicit affected versions
33 explicit affected versions
23 explicit affected versions
37 explicit affected versions
10 explicit affected versions
1 explicit affected versions
102 explicit affected versions
11 explicit affected versions
12 explicit affected versions
125 explicit affected versions
7 explicit affected versions
53 explicit affected versions
118 explicit affected versions
69 explicit affected versions
153 explicit affected versions
26 explicit affected versions
16 explicit affected versions
1 explicit affected versions
46 explicit affected versions
7 explicit affected versions
13 explicit affected versions
16 explicit affected versions
125 explicit affected versions
66 explicit affected versions
16 explicit affected versions
70 explicit affected versions
17 explicit affected versions
3 explicit affected versions
119 explicit affected versions
79 explicit affected versions
1 explicit affected versions
2 explicit affected versions
51 explicit affected versions
78 explicit affected versions
12 explicit affected versions
59 explicit affected versions
56 explicit affected versions
27 explicit affected versions
43 explicit affected versions
109 explicit affected versions
1 explicit affected versions
1 explicit affected versions
83 explicit affected versions
7 explicit affected versions
13 explicit affected versions
13 explicit affected versions
98 explicit affected versions
13 explicit affected versions
62 explicit affected versions
80 explicit affected versions
10 explicit affected versions
12 explicit affected versions
16 explicit affected versions
96 explicit affected versions
69 explicit affected versions
43 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
45 explicit affected versions
37 explicit affected versions
17 explicit affected versions
14 explicit affected versions
69 explicit affected versions
38 explicit affected versions
9 explicit affected versions
11 explicit affected versions
8 explicit affected versions
7 explicit affected versions
7 explicit affected versions
86 explicit affected versions
129 explicit affected versions
108 explicit affected versions
4 explicit affected versions
57 explicit affected versions
58 explicit affected versions
1 explicit affected versions
1 explicit affected versions
67 explicit affected versions
101 explicit affected versions
57 explicit affected versions
13 explicit affected versions
43 explicit affected versions
64 explicit affected versions
132 explicit affected versions
106 explicit affected versions
153 explicit affected versions
10 explicit affected versions
8 explicit affected versions
12 explicit affected versions
76 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
1 explicit affected versions
55 explicit affected versions
110 explicit affected versions
10 explicit affected versions
58 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8
- https://git.kernel.org/stable/c/3c6b4bcf37845c9359aed926324bed66bdd2448d
- https://git.kernel.org/stable/c/71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8
- https://git.kernel.org/stable/c/98cc18b1b71e23fe81a5194ed432b20c2d81a01a
- https://ubuntu.com/security/CVE-2024-46787
- https://ubuntu.com/security/notices/USN-7154-1
- https://ubuntu.com/security/notices/USN-7154-2
- https://ubuntu.com/security/notices/USN-7155-1
- https://ubuntu.com/security/notices/USN-7156-1
- https://ubuntu.com/security/notices/USN-7196-1
- https://ubuntu.com/security/notices/USN-7607-1
- https://ubuntu.com/security/notices/USN-7607-2
- https://ubuntu.com/security/notices/USN-7607-3
- https://ubuntu.com/security/notices/USN-7608-1
- https://ubuntu.com/security/notices/USN-7608-2
- https://ubuntu.com/security/notices/USN-7608-3
- https://ubuntu.com/security/notices/USN-7608-4
- https://ubuntu.com/security/notices/USN-7608-5
- https://ubuntu.com/security/notices/USN-7608-6
- https://ubuntu.com/security/notices/USN-7608-7
- https://ubuntu.com/security/notices/USN-7627-1
- https://ubuntu.com/security/notices/USN-7627-2
- https://ubuntu.com/security/notices/USN-7655-1
- https://ubuntu.com/security/notices/USN-7671-1
- https://ubuntu.com/security/notices/USN-7671-2
- https://ubuntu.com/security/notices/USN-7671-3
- https://ubuntu.com/security/notices/USN-7686-1
- https://ubuntu.com/security/notices/USN-7712-1
- https://ubuntu.com/security/notices/USN-7712-2
- https://www.cve.org/CVERecord?id=CVE-2024-46787