linux-kernel - Re: [syzbot] [mm?] KASAN: slab-use-after-free Read 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aU-IVkmsD1IN2joN@hyeyoo>
Date: Sat, 27 Dec 2025 16:18:46 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: syzbot <syzbot+5272541ccbbb14e2ec30@...kaller.appspotmail.com>
Cc: Liam.Howlett@...cle.com, akpm@...ux-foundation.org, david@...nel.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?] KASAN: slab-use-after-free Read in
 folio_remove_rmap_ptes

On Fri, Dec 26, 2025 at 07:01:39PM +0900, Harry Yoo wrote:
> On Thu, Dec 25, 2025 at 11:48:22PM -0800, syzbot wrote:
> > Last potentially related work creation:
> >  kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
> >  kasan_record_aux_stack+0xa7/0xc0 mm/kasan/generic.c:556
> >  slab_free_hook mm/slub.c:2501 [inline]
> >  slab_free mm/slub.c:6670 [inline]
> >  kmem_cache_free+0x15e/0x770 mm/slub.c:6781
> >  anon_vma_free mm/rmap.c:136 [inline]
> >  __put_anon_vma+0x114/0x3a0 mm/rmap.c:2780
> >  put_anon_vma include/linux/rmap.h:117 [inline]
> >  unlink_anon_vmas+0x58a/0x820 mm/rmap.c:443
> >  dontunmap_complete mm/mremap.c:1265 [inline]
> 
> And then (potentially) it was freed due to MREMAP_DONTUNMAP.
> If it's correct, now we know when the refcount has been dropped to zero!
> 
> In dontunmap_complete():
> > if (new_vma != vrm_vma && start == old_start && end == old_end)
> >        unlink_anon_vmas(vrm->vma)
> 
> It calls unlink_anon_vmas() on the old VMA if the new range is not
> merged into the old VMA.
> 
> Hmm I'm having difficult time understanding how the commit 1583aa278f5
> ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success")
> is supposed to work when the new range is merged into an existing
> VMA (that is not the old VMA itself).
> 
> The merge will succeed only if the other VMA doesn't have anon_vma
> or it has the same anon_vma... which means we're reusing anon_vma
> of the old vma, but we're calling put_anon_vma() on it?

Hmm, no. I tried to write a repro but it didn't work because we free
an anon_vma only when its root rb node is empty.

Looks like I'm still missing something; How can it be empty
when it's actually in use?

-- 
Cheers,
Harry / Hyeonggon