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

[Harry Yoo <harry.yoo@oracle.com>]

On Thu, Jan 01, 2026 at 10:09:06PM +0900, Jeongjun Park wrote:
> 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.
> >

Hi Jeongjun,

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

Oh, great. Thanks!

Could you please elaborate how you confirmed the bad commit?

- Did you perform git bisection on it?
- How did you reproduce the bug and how long did it take to reproduce?

> 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?

It's late at night, so...
let me look at at this tomorrow with a clearer mind :)

Happy new year, by the way!

-- 
Cheers,
Harry / Hyeonggon