CVE-2024-46787: userfaultfd: fix checks for huge PMDs

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

userfaultfd: fix checks for huge PMDs

Patch series "userfaultfd: fix races around pmdtranshuge() check", v2.

The pmdtranshuge() code in mfillatomic() is wrong in three different ways depending on kernel version:

1. The pmdtranshuge() check is racy and can lead to a BUGON() (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, pmdtranshuge() 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 trytomigrate()) against UFFDIOZEROPAGE - on my x86 VM, that causes a kernel oops in ptlockptr(). 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 BUGON() checks in mfillatomic() are just wrong.

I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for <a class="bzbuglink bzstatusCLOSED bzclosed bzpublic " title="CLOSED WONTFIX - Install errors out if squid already installed." href="showbug.cgi?id=3">bug 3</a>), 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:

mfillatomic other thread ============ ============ &lt;zap PMD&gt; pmdpgetlockless() [reads none pmd] &lt;bail if transhuge&gt; &lt;if none:&gt; &lt;pagefault creates transhuge zeropage&gt; ptealloc [no-op] &lt;zap PMD&gt; &lt;bail if pmdtranshuge(dstpmd)&gt; BUGON(pmdnone(dstpmd))

I have experimentally verified this in a kernel with extra mdelay() calls; the BUGON(pmdnone(dstpmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pteoffsetmaplock to fail"), this can't lead to anything worse than a BUGON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (&lt;=6.4), I think we could probably theoretically race past the two BUGON() 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 pmdtranshuge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs).

On &lt;=6.4, this is worse than the first issue: If mfillatomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pteoffsetmaplock(), 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 pmdtranshuge() before ptealloc() - that's redundant, we're going to have to check for that after the ptealloc() anyway.

Backport note: pmdpgetlockless() is pmdreadatomic() in older kernels.