In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the
page index for hugetlb_fault_mutex_hash(). However, linear_page_index()
returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()
expects the index in huge page units (as calculated by
vma_hugecache_offset()). This mismatch means that different addresses
within the same huge page can produce different hash values, leading to
the use of different mutexes for the same huge page. This can cause
races between faulting threads, which can corrupt the reservation map
and trigger the BUG_ON in resv_map_release().

Fix this by replacing linear_page_index() with vma_hugecache_offset()
and applying huge_page_mask() to align the address properly. To make
vma_hugecache_offset() available outside of mm/hugetlb.c, move it to
include/linux/hugetlb.h as a static inline function.

Fixes: 60d4d2d2b40e ("userfaultfd: hugetlbfs: add __mcopy_atomic_hugetlb for huge page UFFDIO_COPY")
Reported-by: syzbot+f525fd79634858f478e7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7
Cc: stable@vger.kernel.org
Signed-off-by: Jianhui Zhou <jianhuizzzzz@gmail.com>
---
v2:
- Remove unnecessary !CONFIG_HUGETLB_PAGE stub for vma_hugecache_offset()
  (Peter Xu, SeongJae Park)

 include/linux/hugetlb.h | 11 +++++++++++
 mm/hugetlb.c            | 11 -----------
 mm/userfaultfd.c        |  5 ++++-
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 65910437be1c..f003afe0cc91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -796,6 +796,17 @@ static inline unsigned huge_page_shift(struct hstate *h)
 	return h->order + PAGE_SHIFT;
 }
 
+/*
+ * Convert the address within this vma to the page offset within
+ * the mapping, huge page units here.
+ */
+static inline pgoff_t vma_hugecache_offset(struct hstate *h,
+		struct vm_area_struct *vma, unsigned long address)
+{
+	return ((address - vma->vm_start) >> huge_page_shift(h)) +
+		(vma->vm_pgoff >> huge_page_order(h));
+}
+
 static inline bool order_is_gigantic(unsigned int order)
 {
 	return order > MAX_PAGE_ORDER;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 0beb6e22bc26..b87ed652c748 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1006,17 +1006,6 @@ static long region_count(struct resv_map *resv, long f, long t)
 	return chg;
 }
 
-/*
- * Convert the address within this vma to the page offset within
- * the mapping, huge page units here.
- */
-static pgoff_t vma_hugecache_offset(struct hstate *h,
-			struct vm_area_struct *vma, unsigned long address)
-{
-	return ((address - vma->vm_start) >> huge_page_shift(h)) +
-			(vma->vm_pgoff >> huge_page_order(h));
-}
-
 /**
  * vma_kernel_pagesize - Page size granularity for this VMA.
  * @vma: The user mapping.
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 927086bb4a3c..8efebc47a410 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -507,6 +507,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
 	pgoff_t idx;
 	u32 hash;
 	struct address_space *mapping;
+	struct hstate *h;
 
 	/*
 	 * There is no default zero huge page for all huge page sizes as
@@ -564,6 +565,8 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
 			goto out_unlock;
 	}
 
+	h = hstate_vma(dst_vma);
+
 	while (src_addr < src_start + len) {
 		VM_WARN_ON_ONCE(dst_addr >= dst_start + len);
 
@@ -573,7 +576,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
 		 * in the case of shared pmds.  fault mutex prevents
 		 * races with other faulting threads.
 		 */
-		idx = linear_page_index(dst_vma, dst_addr);
+		idx = vma_hugecache_offset(h, dst_vma, dst_addr & huge_page_mask(h));
 		mapping = dst_vma->vm_file->f_mapping;
 		hash = hugetlb_fault_mutex_hash(mapping, idx);
 		mutex_lock(&hugetlb_fault_mutex_table[hash]);
-- 
2.43.0

On 3/7/26 15:35, Jianhui Zhou wrote:
> In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the
> page index for hugetlb_fault_mutex_hash(). However, linear_page_index()
> returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()
> expects the index in huge page units (as calculated by
> vma_hugecache_offset()). This mismatch means that different addresses
> within the same huge page can produce different hash values, leading to
> the use of different mutexes for the same huge page. This can cause
> races between faulting threads, which can corrupt the reservation map
> and trigger the BUG_ON in resv_map_release().
> 
> Fix this by replacing linear_page_index() with vma_hugecache_offset()
> and applying huge_page_mask() to align the address properly. To make
> vma_hugecache_offset() available outside of mm/hugetlb.c, move it to
> include/linux/hugetlb.h as a static inline function.
> 
> Fixes: 60d4d2d2b40e ("userfaultfd: hugetlbfs: add __mcopy_atomic_hugetlb for huge page UFFDIO_COPY")
> Reported-by: syzbot+f525fd79634858f478e7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7
> Cc: stable@vger.kernel.org
> Signed-off-by: Jianhui Zhou <jianhuizzzzz@gmail.com>
> ---
> v2:
> - Remove unnecessary !CONFIG_HUGETLB_PAGE stub for vma_hugecache_offset()
>   (Peter Xu, SeongJae Park)
> 
>  include/linux/hugetlb.h | 11 +++++++++++
>  mm/hugetlb.c            | 11 -----------
>  mm/userfaultfd.c        |  5 ++++-
>  3 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 65910437be1c..f003afe0cc91 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -796,6 +796,17 @@ static inline unsigned huge_page_shift(struct hstate *h)
>  	return h->order + PAGE_SHIFT;
>  }
>  
> +/*
> + * Convert the address within this vma to the page offset within
> + * the mapping, huge page units here.
> + */
> +static inline pgoff_t vma_hugecache_offset(struct hstate *h,
> +		struct vm_area_struct *vma, unsigned long address)
> +{
> +	return ((address - vma->vm_start) >> huge_page_shift(h)) +
> +		(vma->vm_pgoff >> huge_page_order(h));
> +}

It's hard to put my disgust about the terminology "hugecache" into
words. Not your fault, but we should do better :)

If you're starting to use that from other MM code then hugetlb.c, please
find a better name.

Further, I wonder whether we can avoid passing in "struct hstate *h" and
simply call hstate_vma() internally.

Something like the following to mimic linear_page_index() ?

/**
 * hugetlb_linear_page_index - linear_page_index() but in hugetlb page
 *			       size granularity
 * @vma: ...
 * @address: ...
 *
 * Returns: ...
 */
static inline void hugetlb_linear_page_index(struct vm_area_struct *vma,
		unsigned long address)
{
	struct hstate *h = hstate_vma(vma);

	...
}

-- 
Cheers,

David

On Mon, Mar 09, 2026 at 05:47:26PM +0100, David Hildenbrand wrote:
> It's hard to put my disgust about the terminology "hugecache" into
> words. Not your fault, but we should do better :)
>
> If you're starting to use that from other MM code then hugetlb.c, please
> find a better name.
>
> Further, I wonder whether we can avoid passing in "struct hstate *h" and
> simply call hstate_vma() internally.
>
> Something like the following to mimic linear_page_index() ?

Agreed. I'll add hugetlb_linear_page_index() in include/linux/hugetlb.h
with hstate_vma() called internally, and keep vma_hugecache_offset() as
a static function in mm/hugetlb.c untouched. Will send v4.

Thanks!

On Sat, 7 Mar 2026, Jianhui Zhou wrote:

> In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the
> page index for hugetlb_fault_mutex_hash(). However, linear_page_index()
> returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()
> expects the index in huge page units (as calculated by
> vma_hugecache_offset()). This mismatch means that different addresses
> within the same huge page can produce different hash values, leading to
> the use of different mutexes for the same huge page. This can cause
> races between faulting threads, which can corrupt the reservation map
> and trigger the BUG_ON in resv_map_release().
> 
> Fix this by replacing linear_page_index() with vma_hugecache_offset()
> and applying huge_page_mask() to align the address properly. To make
> vma_hugecache_offset() available outside of mm/hugetlb.c, move it to
> include/linux/hugetlb.h as a static inline function.
> 
> Fixes: 60d4d2d2b40e ("userfaultfd: hugetlbfs: add __mcopy_atomic_hugetlb for huge page UFFDIO_COPY")

I have not thought it through, nor checked (someone else please do so
before this might reach stable trees); but I believe it's very likely
that that Fixes attribution to a 4.11 commit is wrong - more likely 6.7's
a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c").

Hugh

On Sun, Mar 08, 2026, Hugh Dickins wrote:
> I have not thought it through, nor checked (someone else please do so
> before this might reach stable trees); but I believe it's very likely
> that that Fixes attribution to a 4.11 commit is wrong - more likely 6.7's
> a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c").

You are right. Before a08c7193e4f1, linear_page_index() called
linear_hugepage_index() for hugetlb VMAs, which returned the index in
huge page units. The bug was introduced when a08c7193e4f1 removed that
special casing but missed updating the caller in mm/userfaultfd.c.

I will fix the Fixes tag in v3. Thanks!

Hugh Dickins <hughd@google.com> 于2026年3月9日周一 10:09写道：
>
> On Sat, 7 Mar 2026, Jianhui Zhou wrote:
>
> > In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the
> > page index for hugetlb_fault_mutex_hash(). However, linear_page_index()
> > returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()
> > expects the index in huge page units (as calculated by
> > vma_hugecache_offset()). This mismatch means that different addresses
> > within the same huge page can produce different hash values, leading to
> > the use of different mutexes for the same huge page. This can cause
> > races between faulting threads, which can corrupt the reservation map
> > and trigger the BUG_ON in resv_map_release().
> >
> > Fix this by replacing linear_page_index() with vma_hugecache_offset()
> > and applying huge_page_mask() to align the address properly. To make
> > vma_hugecache_offset() available outside of mm/hugetlb.c, move it to
> > include/linux/hugetlb.h as a static inline function.
> >
> > Fixes: 60d4d2d2b40e ("userfaultfd: hugetlbfs: add __mcopy_atomic_hugetlb for huge page UFFDIO_COPY")
>
> I have not thought it through, nor checked (someone else please do so
> before this might reach stable trees); but I believe it's very likely
> that that Fixes attribution to a 4.11 commit is wrong - more likely 6.7's
> a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c").
>
> Hugh