Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in folio_remove_rmap_ptes

[Harry Yoo]

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