Re: [PATCH 02/10] mm/hugetlb: fix use-after-free of a new anon folio

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

> On Oct 16, 2026, at 00:07, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> From: Josef Bacik <josef@toxicpanda.com>
> 
> For a fault in a private mapping with nothing in the page cache,
> hugetlb_no_page() allocates a folio, locks it and maps it.  The folio has
> one reference, which belongs to the page table entry from then on.  After
> dropping the page table lock the function still sets the migratable flag
> of the folio and unlocks it.
> 
> Whoever zaps the entry in between frees the folio.  The fault holds the
> fault mutex and the lock of the vma.  MADV_DONTNEED and the first unmap of
> a hole punch, hugetlb_vmdelete_list(), do not take the fault mutex, and a
> private vma only has a lock if it owns a reservation map: not with
> MAP_NORESERVE, and not in the child after fork().
> 
> Then the flag is set in, and folio_unlock() is called on, a folio that is
> free or has a new owner.  A surplus page goes back to the page allocator
> while it is locked:
> 
>  BUG: Bad page state in process init  pfn:108e00
>  flags: 0x200000000000059(locked|uptodate|dirty|head|node=0|zone=2)
>  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> 
> A page of the pool can be given to the next user, of any file, who locks
> it and loses the lock to the late folio_unlock():
> 
>  kernel BUG at mm/filemap.c:1532!
>   hugetlb_no_page+0x111b/0x23e0
>   hugetlb_fault+0x3a9/0x14a0
> 
> An unprivileged process is enough: threads that write to a MAP_PRIVATE |
> MAP_NORESERVE hugetlb mapping, threads that call MADV_DONTNEED on it, and
> one that takes the freed pages for another file.
> 
> Until commit 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more
> pmd sharing synchronization") the fault held i_mmap_rwsem for reading,
> which everybody who zaps takes for writing.  The lock that commit
> bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") gave
> to private vmas closed the window again, but only for those with a
> reservation map.
> 
> Be done with the folio before the page table lock is dropped, as
> hugetlb_wp() is with its copy.  The function already unlocks page cache
> folios under that lock.
> 
> Original fix generated by an LLM and sent in private by Josef.
> 
> Fixes: 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization")
> Cc: stable@vger.kernel.org
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> [ david: simplify+move comment ]
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

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

Thanks.