UBUNTU-CVE-2026-72174: Medium severity ubuntu/linux-hwe-edge vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In fs/proc/task_mmu pagemap_scan_pte_hole(), fault in the page table and install the uffd-wp marker directly with make_uffd_wp_huge_pte() under the page-table lock instead of calling uffd_wp_range().
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are listed as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-hwe-edge, and ubuntu/linux-gkeop.
What conditions trigger the hang?
A process must issue a PAGEMAP_SCAN ioctl with PM_SCAN_WP_MATCHING against a hugetlb VMA, and the scan must reach an unpopulated portion of that range. The issue does not occur on the populated hugetlb entry path described in the advisory.
How can an administrator recognize that the issue has occurred?
The calling thread hangs when the scan reaches the unpopulated hugetlb range. The advisory states that the thread is unkillable because it blocks waiting for a write lock while retaining the corresponding read lock.