CVE-2022-49760 — mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()

Affected: Linux

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

mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()

Patch series "mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()".

Playing with virtio-mem and background snapshots (using uffd-wp) on hugetlb in QEMU, I managed to trigger a VM_BUG_ON(). Looking into the details, hugetlb_change_protection() seems to not handle uffd-wp correctly in all cases.

Patch #1 fixes my test case. I don't have reproducers for patch #2, as it requires running into migration entries.

I did not yet check in detail yet if !hugetlb code requires similar care.

This patch (of 2):

There are two problematic cases when stumbling over a PTE marker in hugetlb_change_protection():

(1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will end up in the "!huge_pte_none(pte)" case and mess up the PTE marker.

(2) We unprotect a uffd-wp PTE marker: we will similarly end up in the "!huge_pte_none(pte)" case even though we cleared the PTE, because the "pte" variable is stale. We'll mess up the PTE marker.

For example, if we later stumble over such a "wrongly modified" PTE marker, we'll treat it like a present PTE that maps some garbage page.

This can, for example, be triggered by mapping a memfd backed by huge pages, registering uffd-wp, uffd-wp'ing an unmapped page and (a) uffd-wp'ing it a second time; or (b) uffd-unprotecting it; or (c) unregistering uffd-wp. Then, ff we trigger fallocate…

Most recent entries from all

CVE-2022-49760 — mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()