[PATCH 07/15] hugetlbfs: fix unmapping folios from private VMAs
From: David Hildenbrand (Arm)
Date: Wed Oct 28 2026 - 16:57:21 EST
From: Josef Bacik <josef@xxxxxxxxxxxxxx>
hugetlb_unmap_file_folio() assumes vm_private_data points to a struct
hugetlb_vma_lock when hugetlb_vma_trylock_write() fails. Since hugetlb VMA
locking was extended to private VMAs, this can also happen when
vm_private_data contains a resv_map pointer; treating it as a
hugetlb_vma_lock corrupts memory and can cause crashes or hangs.
Only take the VMA lock when a shareable lock exists, as additional locking
is only needed for PMD table sharing. The fault mutex and i_mmap_rwsem
already provide the required protection for private VMAs.
Fix generated by an LLM and sent by Josef Bacik in private.
Fixes: bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs")
Cc: stable@xxxxxxxxxx
Tested-by: Daehyeon Ko <4ncienth@xxxxxxxxx>
Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
[ david: simplify description and comment ]
Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
---
fs/hugetlbfs/inode.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 5592cfc6cc8b..fa367fc9e019 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -400,6 +400,16 @@ static void hugetlb_unmap_file_folio(struct hstate *h,
if (!hugetlb_vma_maps_pfn(vma, v_start, pfn))
continue;
+ /*
+ * We only need additional VMA locking here for PMD table
+ * sharing, which synchronizes on the shareable lock.
+ */
+ if (!__vma_shareable_lock(vma)) {
+ unmap_hugepage_range(vma, v_start, v_end, NULL,
+ ZAP_FLAG_DROP_MARKER);
+ continue;
+ }
+
if (!hugetlb_vma_trylock_write(vma)) {
vma_lock = vma->vm_private_data;
/*
--
2.43.0