Re: [PATCH 1/2] mm/hugetlb: fix list corruption in allocate_file_region_entries()

[Muchun Song <muchun.song@linux.dev>]

> On Jul 14, 2026, at 01:14, Xiangfeng Cai <caixiangfeng@bytedance.com> wrote:
> 
> allocate_file_region_entries() tops up resv->region_cache with freshly
> allocated file_region descriptors.  The allocation uses GFP_KERNEL, so
> resv->lock is dropped around it: the new entries are gathered on a
> stack-local list head, allocated_regions, and spliced into
> resv->region_cache once the lock is re-acquired.
> 
> The splice used list_splice(), which moves the entries but does not
> re-initialize the source head, so allocated_regions is left pointing at an
> entry that now lives on resv->region_cache.  The top-up runs in a while
> loop that re-checks the cache deficit after re-acquiring the lock.  For a
> shared mapping the resv_map is shared by every mapper of the hugetlbfs
> inode, so a concurrent region_chg()/region_add()/region_del() on the same
> resv_map can consume cache entries during the unlocked window and force a
> second iteration.  That iteration calls list_add() on the stale head and
> corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check
> trips:
> 
>  list_add corruption. next->prev should be prev (ffffc900011ff7f8),
>  but was ffff88814c281460. (next=ffff88814c545640).
>  kernel BUG at lib/list_debug.c:31!
>   allocate_file_region_entries+0x191/0x420
>   region_chg+0x267/0x300
>   hugetlb_reserve_pages+0x387/0xc80
>   hugetlbfs_file_mmap+0x2ce/0x3f0
>   mmap_region+0x1348/0x1a80
>   do_mmap+0x85e/0xb90
>   vm_mmap_pgoff+0x18c/0x330
>   ksys_mmap_pgoff+0x2a1/0x3e0
>   do_syscall_64+0xd7/0x420
> 
> Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack
> address into resv->region_cache, leading to later use-after-free.
> 
> Use list_splice_init() so the source head is re-initialized empty after
> each splice, making the retry loop safe.
> 
> Fixes: d3ec7b6e09e5 ("mm/hugetlb: use list_splice to merge two list at once")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com>

Reviewed-by: Muchun Song <muchun.song@linux.dev>

Thanks.