Re: [syzbot] [mm?] WARNING in folio_remove_rmap_ptes

[Jeongjun Park]

Harry Yoo wrote:
> On Tue, Dec 30, 2025 at 11:02:18PM +0100, David Hildenbrand (Red Hat) wrote:
> > On 12/24/25 06:35, Harry Yoo wrote:
> > > On Mon, Dec 22, 2025 at 09:23:17PM -0800, syzbot wrote:
> > > Perhaps we want yet another DEBUG_VM feature to record when it's been
> > > dropped to zero and report it in the sanity check, or... imagine harder
> > > how a file VMA that has anon_vma involving CoW / GUP / migration /
> > > reclamation could somehow drop the refcount to zero?
> > > 
> > > Sounds fun ;)
> > > 
> > 
> > Can we bisect the issue given that we have a reproducer?
> 
> Unfortunately I could not reproduce the issue with the C reproducer,
> even with the provided kernel config. Maybe it's a race condition and
> I didn't wait long enough...
> 
> > This only popped up just now, so I would assume it's actually something that
> > went into this release that makes it trigger.
> 
> I was assuming the bug has been there even before the addition of
> VM_WARN_ON_ONCE(), as the commit a222439e1e27 ("mm/rmap: add anon_vma
> lifetime debug check") says:
> > There have been syzkaller reports a few months ago[1][2] of UAF in rmap
> > walks that seems to indicate that there can be pages with elevated
> > mapcount whose anon_vma has already been freed, but I think we never
> > figured out what the cause is; and syzkaller only hit these UAFs when
> > memory pressure randomly caused reclaim to rmap-walk the affected pages,
> > so it of course didn't manage to create a reproducer.
> > 
> > Add a VM_WARN_ON_FOLIO() when we add/remove mappings of anonymous folios
> > to hopefully catch such issues more reliably.
>

I tested this myself and found that the bug is caused by commit
d23cb648e365 ("mm/mremap: permit mremap() move of multiple VMAs").

This commit doesn't mention anything about MREMAP_DONTUNMAP. Is it really
acceptable for MREMAP_DONTUNMAP, which maintains old_address and aliases
new_address, to use move-only fastpath?

If MREMAP_DONTUNMAP can also use fastpath, I think a sophisticated
refactoring of remap_move is needed to manage anon_vma/rmap lifetimes.
Otherwise, adding simple flag check logic to vrm_move_only() is likely
necessary.

What are your thoughts?

> -- 
> Cheers,
> Harry / Hyeonggon

Regards,
Jeongjun Park