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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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().  To write-protect the hole
that handler calls uffd_wp_range(), which on a hugetlb VMA reaches
hugetlb_change_protection() and takes the same vma lock for write.  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().  That is the same sequence
hugetlb_change_protection() runs for an unpopulated entry, minus the vma
write lock -- which is safe to skip because PMD sharing is disabled on
uffd-wp VMAs (hugetlb_unshare_all_pmds() runs at registration), leaving
nothing for that lock to serialise against.

The Linux kernel CVE team has assigned CVE-2026-72174 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.7 with commit 52526ca7fdb905a768a93f8faa418e9b988fc34b and fixed in 6.12.97 with commit a6ac03652d9edc30c2912037ac83beb42cc67f8e
	Issue introduced in 6.7 with commit 52526ca7fdb905a768a93f8faa418e9b988fc34b and fixed in 6.18.40 with commit 43b987ed35be9be21a303d1036d4241fec9943df
	Issue introduced in 6.7 with commit 52526ca7fdb905a768a93f8faa418e9b988fc34b and fixed in 7.1.5 with commit 18b8a9700610299819d21fd0ea85d24726d17f65
	Issue introduced in 6.7 with commit 52526ca7fdb905a768a93f8faa418e9b988fc34b and fixed in 7.2-rc1 with commit e92d92bbafb264dc0518d52b846a3c07ed8d523f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-72174
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/proc/task_mmu.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/a6ac03652d9edc30c2912037ac83beb42cc67f8e
	https://git.kernel.org/stable/c/43b987ed35be9be21a303d1036d4241fec9943df
	https://git.kernel.org/stable/c/18b8a9700610299819d21fd0ea85d24726d17f65
	https://git.kernel.org/stable/c/e92d92bbafb264dc0518d52b846a3c07ed8d523f