CVE-2026-72174: fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()

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

fs/proc/taskmmu: fix hugetlb self-deadlock in pagemapscanptehole()

A PAGEMAPSCAN ioctl requesting PMSCANWPMATCHING on a hugetlb VMA hangs the calling thread, unkillably, as soon as the scan reaches an unpopulated part of the range:

dopagemapscan() walkpagerange() walkhugetlbrange() hugetlbvmalockread() # take the vma lock for read ... pagemapscanptehole() # ... ->ptehole() for a hole uffdwprange() changeprotection() hugetlbchangeprotection() hugetlbvmalockwrite() # ... and block taking it for write

walkhugetlbrange() holds the hugetlb vma lock for read across the whole walk. A present entry goes to ->hugetlbentry(); an unpopulated one goes to ->ptehole(), i.e. pagemapscanptehole(). To write-protect the hole that handler calls uffdwprange(), which on a hugetlb VMA reaches hugetlbchangeprotection() and takes the same vma lock for write. The thread then blocks in downwrite() waiting for the read lock it is itself holding.

The populated path avoids this: pagemapscanhugetlbentry() write-protects the entry inline under the page-table lock and never enters hugetlbchangeprotection().

Do the same for holes. Fault in the page table and install the uffd-wp marker directly with makeuffdwphugepte() under the page-table lock, rather than routing through uffdwprange(). That is the same sequence hugetlbchangeprotection() runs for an unpopulated entry, minus the vma write lock -- which is safe to skip because PMD sharing is disabled on uffd-wp VMAs (hugetlbunshareallpmds() runs at registration), leaving nothing for that lock to serialise against.