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

[Lance Yang <lance.yang@linux.dev>]

On Thu, Oct 15, 2026 at 06:07:08PM +0200, David Hildenbrand (Arm) 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>
>---

Nice work! Nothing jumped out at me, so:

Reviewed-by: Lance Yang <lance.yang@linux.dev>