cbcvebase.
CVE-2024-46787
published 2024-09-18

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…

PriorityP417medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.21%
12.1th percentile
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 ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] 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(), s

Affected

20 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.10.11-1 (forky)linux 6.10.11-1 (forky)
linuxlinux
linuxlinux>= c1a4de99fada21e2e9251e52cbb51eff5aadc757 < 3c6b4bcf37845c9359aed926324bed66bdd2448d3c6b4bcf37845c9359aed926324bed66bdd2448d
linuxlinux>= c1a4de99fada21e2e9251e52cbb51eff5aadc757 < 98cc18b1b71e23fe81a5194ed432b20c2d81a01a98cc18b1b71e23fe81a5194ed432b20c2d81a01a
linuxlinux>= c1a4de99fada21e2e9251e52cbb51eff5aadc757 < 71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d871c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.10.11-16.10.11-1
linuxlinux_kernel>= 0 < 6.10.11-16.10.11-1
linuxlinux_kernel>= 0 < 5.15.0-143.1535.15.0-143.153
linuxlinux_kernel>= 0 < 6.8.0-50.516.8.0-50.51
linuxlinux_kernel>= 0 < 4.4.0-270.3044.4.0-270.304
linuxlinux_kernel>= 0 < 4.15.0-239.2514.15.0-239.251
linuxlinux_kernel>= 0 < 5.4.0-219.2395.4.0-219.239
linuxlinux_kernel>= 4.3 < 6.6.516.6.51
linuxlinux_kernel>= 6.7 < 6.10.106.10.10

CVSS provenance

nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv8.8HIGH
vendor_ubuntu8.8HIGH
vendor_debian4.7MEDIUM
vendor_redhat4.7MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.