> On Jul 14, 2026, at 01:14, Xiangfeng Cai <[email protected]> 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: <[email protected]>
> Signed-off-by: Xiangfeng Cai <[email protected]>
Reviewed-by: Muchun Song <[email protected]>
Thanks.
