linux-kernel - Re: [syzbot] [mm?] WARNING in folio_remove_rmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aVTJt9M-A1BL8w5O@hyeyoo>
Date: Wed, 31 Dec 2025 15:59:03 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: syzbot <syzbot+b165fc2e11771c66d8ba@...kaller.appspotmail.com>,
        Liam.Howlett@...cle.com, akpm@...ux-foundation.org, jannh@...gle.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        lorenzo.stoakes@...cle.com, riel@...riel.com,
        syzkaller-bugs@...glegroups.com, vbabka@...e.cz
Subject: Re: [syzbot] [mm?] WARNING in folio_remove_rmap_ptes

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