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

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

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.

-- 
Cheers,
Harry / Hyeonggon