Medium [CVE-2026-72174] fix hugetlb self-deadlock in pagemap_scan_pte_hole

In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole() A PAGEMAP_SCAN ioctl requesting PM_SCAN_WP_MATCHING on a hugetlb VMA hangs the calling thread, unkillably, as soon as the scan reaches an unpopulated part of the range: do_pagemap_scan() walk_page_range() walk_hugetlb_range() hugetlb_vma_lock_read() # take the vma lock for read... pagemap_scan_pte_hole() #... ->pte_hole() for a hole uffd_wp_range() change_protection() hugetlb_change_protection() hugetlb_vma_lock_write() #... and block taking it for write walk_hugetlb_range() holds the hugetlb vma lock for read across the whole walk.

A present entry goes to ->hugetlb_entry(); an unpopulated one goes to ->pte_hole(), i.e. pagemap_scan_pte_hole(). The thread then blocks in down_write() waiting for the read lock it is itself holding.

The populated path avoids this: pagemap_scan_hugetlb_entry() write-protects the entry inline under the page-table lock and never enters hugetlb_change_protection(). Do the same for holes.

Fault in the page table and install the uffd-wp marker directly with make_uffd_wp_huge_pte() under the page-table lock, rather than routing through uffd_wp_range(). A local attacker could trigger a self-deadlock condition within the huge pages (hugetlb) memory management subsystem.