GHSA-XXR9-W8RG-G2H6
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-15 06:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-72174"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:21:35Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()\n\nA PAGEMAP_SCAN ioctl requesting PM_SCAN_WP_MATCHING on a hugetlb VMA hangs\nthe calling thread, unkillably, as soon as the scan reaches an unpopulated\npart of the range:\n\n do_pagemap_scan()\n walk_page_range()\n walk_hugetlb_range()\n hugetlb_vma_lock_read() # take the vma lock for read ...\n pagemap_scan_pte_hole() # ... -\u003epte_hole() for a hole\n uffd_wp_range()\n change_protection()\n hugetlb_change_protection()\n hugetlb_vma_lock_write() # ... and block taking it for write\n\nwalk_hugetlb_range() holds the hugetlb vma lock for read across the whole\nwalk. A present entry goes to -\u003ehugetlb_entry(); an unpopulated one goes\nto -\u003epte_hole(), i.e. pagemap_scan_pte_hole(). To write-protect the hole\nthat handler calls uffd_wp_range(), which on a hugetlb VMA reaches\nhugetlb_change_protection() and takes the same vma lock for write. The\nthread then blocks in down_write() waiting for the read lock it is itself\nholding.\n\nThe populated path avoids this: pagemap_scan_hugetlb_entry()\nwrite-protects the entry inline under the page-table lock and never enters\nhugetlb_change_protection().\n\nDo the same for holes. Fault in the page table and install the uffd-wp\nmarker directly with make_uffd_wp_huge_pte() under the page-table lock,\nrather than routing through uffd_wp_range(). That is the same sequence\nhugetlb_change_protection() runs for an unpopulated entry, minus the vma\nwrite lock -- which is safe to skip because PMD sharing is disabled on\nuffd-wp VMAs (hugetlb_unshare_all_pmds() runs at registration), leaving\nnothing for that lock to serialise against.",
"id": "GHSA-xxr9-w8rg-g2h6",
"modified": "2026-08-15T06:32:14Z",
"published": "2026-08-15T06:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72174"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18b8a9700610299819d21fd0ea85d24726d17f65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43b987ed35be9be21a303d1036d4241fec9943df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6ac03652d9edc30c2912037ac83beb42cc67f8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e92d92bbafb264dc0518d52b846a3c07ed8d523f"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.