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] [day] [month] [year] [list]

Message-ID: <aVTjvi6FCp1IzQME@hyeyoo>
Date: Wed, 31 Dec 2025 17:50:06 +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 Sat, Dec 27, 2025 at 04:18:46PM +0900, Harry Yoo wrote:
> 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?

What prevents an anon_vma from being reused after the kernel releases
the rmap lock and before it calls put_anon_vma() in unlink_anon_vmas()?

Something like:

T1                                  T2

mremap(MREMAP_DONTUNMAP)
-> dontunmap_complete()
  -> unlink_anon_vmas()                 
     -> lock_anon_vma_root()
     -> remove anon_vmas from
        the chain their rbtrees
	are not empty
     -> unlock_anon_vma_root()
                                  mremap()
				    -> the new range is merged to
				       a vma with an anon_vma
				    -> reuses the anon_vma
     -> call put_anon_vma() on
        anon_vmas in the chain
	(with empty rbtree)

	Oops! it's still in use
	(due to reuse in T2)
	but the kernel called
	put_anon_vma() on it

                                  exit()
				    -> unmaps the all VMAs and sees
				       anon_vma with refcount == 0

-- 
Cheers,
Harry / Hyeonggon