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

[Lorenzo Stoakes <lorenzo.stoakes@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.
> >
>
> 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?

It's not a fast path, it permits multiple VMAs to be moved at once for
convenience (most importantly - to avoid users _having to know_ how the kernel
is going to handle VMA merging esp. in the light of confusing rules around
merging of VMAs that map anonymous memory).

When MREMAP_DONTUMAP is used, it doesn't leave the mapping as-is, it moves all
the page tables, it just leaves the existing VMA where it is.

There should be no problem with doing this. Obviously the fact there's a bug
suggests there _is_ a problem obviously.

This should be no different from individually mremap()'ing each of the VMAs
separately.

>
> If MREMAP_DONTUNMAP can also use fastpath, I think a sophisticated
> refactoring of remap_move is needed to manage anon_vma/rmap lifetimes.

Why exactly?

In dontunmap_complete() we unlink all attached anon_vma's explicitly, assuming
we haven't just merged with the VMA we just moved.

We don't have to do so for file-backed VMAs nor should there be any lifetime
issues because the VMA will fault in from the file on access.


> Otherwise, adding simple flag check logic to vrm_move_only() is likely
> necessary.

I'd say let's figure out the bug and see if there's any necessity for this.

So far I haven't been able to reproduce it locally... :) and it seems you could
only reproduce it once so far?

That makes this something of a pain, seems like a race, the fact the repro uses
BPF is also... not great for nailing this down :)

But I am looking into it.

One possibility is it's relying on a just-so arrangement of VMA's that trigger
some horrible merge corner case, this bit of code:

	/*
	 * anon_vma links of the old vma is no longer needed after its page
	 * table has been moved.
	 */
	if (new_vma != vrm->vma && start == old_start && end == old_end)
		unlink_anon_vmas(vrm->vma);

Makes me wonder if a merge that happens to occur here triggers the
!unlink_anon_vmas() case... but then this really shouldn't be any different from
running mremap() repeatedly for each individual VMA.

>
> What are your thoughts?

As Ash from Alien said - I am collating :)

Happy new year to all... :) Am officially on holiday until Monday but will try
to look into this at least for today/tomorrow.

>
> > --
> > Cheers,
> > Harry / Hyeonggon
>
> Regards,
> Jeongjun Park
>

Cheers, Lorenzo