CVE-2026-72175: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race

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

fs/proc/taskmmu: fix makeuffdwphugepte() prot-update race

Patch series "userfaultfd/pagemap: pre-existing fixes".

These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this.

All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@.

1: fs/proc/taskmmu: a missing hugeptepmodifyprotstart() in makeuffdwphugepte() can lose hardware Dirty/Accessed updates when PAGEMAPSCAN write-protects a hugetlb PTE.

2: fs/proc/taskmmu: pagemapscanhugetlbentry() compares the range against HPAGESIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages.

3: fs/proc/taskmmu: PAGEMAPSCAN with PMSCANWPMATCHING over an unpopulated hugetlb range self-deadlocks -- pagemapscanptehole() calls uffdwprange() while walkhugetlbrange() holds the hugetlb vma lock for read, and hugetlbchangeprotection() then takes it for write. Install the marker inline instead.

4: mm/hugememory: changenonpresenthugepmd() drops pmdswpuffdwp on a device-private PMD permission downgrade, silently losing the uffd-wp marker.

5: userfaultfd: mustwait() applies ptewrite() to a locklessly read PTE without checking ptepresent(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault.

6: userfaultfd: VMAUFFDFLAGS feeds VMAUFFDMINORBIT (41) to mkvmaflags() unconditionally, an out-of-bounds write into the single-word vmaflagst on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised.

This patch (of 6):

makeuffdwphugepte() arms the UFFDWP bit on a present HugeTLB PTE by calling hugeptepmodifyprotcommit() with a ptent snapshot that was fetched without the corresponding hugeptepmodifyprotstart(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and hugeptepmodifyprotcommit() (whose generic implementation just calls sethugepteat()) then writes the stale snapshot back over the live hardware bits, losing the update.

The non-hugetlb sibling makeuffdwppte() does this correctly via ptepmodifyprotstart() / ptepmodifyprotcommit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.