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

[Lorenzo Stoakes (Oracle)]

On Tue, Mar 31, 2026 at 12:43:32PM +0100, Lorenzo Stoakes (Oracle) wrote:
> On Tue, Mar 31, 2026 at 02:07:28AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    e77a5a5cfe43 Add linux-next specific files for 20260326
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13640f52580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=51ca7cbda5f81780
> > dashboard link: https://syzkaller.appspot.com/bug?extid=001b9efd14d3e8fac896
> > compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/63883a48e879/disk-e77a5a5c.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/cfdff9b548ab/vmlinux-e77a5a5c.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/f2e4eca37d44/bzImage-e77a5a5c.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+001b9efd14d3e8fac896@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in madvise_walk_vmas+0x661/0xae0 mm/madvise.c:1726
>
> This is:
>
> 		if (vma && range->end < vma->vm_end) <-- 1726
> 			range->end = vma->vm_end;
>
> > Read of size 8 at addr ffff88803322aa08 by task syz.0.3603/14995
>
> It'd make no sense for a UAF on stack variable range, so it's vma->vm_end
> (offset lines up).
>
> So it means we have a stale vma pointer here in madvise_walk_vmas():
>
> 		error = madvise_vma_behavior(madv_behavior);
> 		if (error)
> 			return error;
> 		if (madv_behavior->lock_dropped) { <--- this is a big clue
> 			/* We dropped the mmap lock, we can't ref the VMA. */
> 			prev = NULL;
> 			vma = NULL;
> 			madv_behavior->lock_dropped = false;
> 		} else {
> 			vma = madv_behavior->vma;
> 			prev = vma;
> 		}
>
> 		if (vma && range->end < vma->vm_end)
> 			range->end = vma->vm_end;
>
> So _after_ the madvise_vma_behavior() call, we won't look at a vma if the lock
> was dropped.
>
> So perhaps we're not correctly propagating this + then getting a stale VMA pointer...
>
> (See below for analysis from registers as to why this is MADV_COLLAPSE)
>
> In madvise_colapse(), we pass the lock_dropped parameter to
> collapse_single_pmd(), which can then set the pointed-to boolean to true.
>
> But then it refreshes the vma via hugepage_vma_revalidate on the next iteration:
>
> 	for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) {
> 		enum scan_result result = SCAN_FAIL;
>
> 		if (*lock_dropped) {
> 			...
> 			mmap_read_lock(mm);
> 			*lock_dropped = false;
> 			result = hugepage_vma_revalidate(mm, addr, false, &vma,
> 							 cc);
> 			...
> 		}
>
> 		result = collapse_single_pmd(addr, vma, lock_dropped, cc);
>
> 		...
> 	}
>
> And something might have raced to change what that VMA is.
>
> However... coming back to madvise_walk_vmas():
>
> 		if (madv_behavior->lock_dropped) {
> 			...
> 		} else {
> 			vma = madv_behavior->vma; <-- we are reading a stale VMA...
> 			prev = vma;		  <-- ...and even assigning it to prev!
> 		}
>
> This whole 'lock dropped' notion is somewhat horrible... I guess it's really
> about detecting a gap in VMAs, which is not exactly crucial since we tolerate
> there being gaps (but return -ENOMEM for some reason to signify it).
>
> Anyway, the proximate fix here is for *lock_dropped in madvise_collapse() to
> actually be relative to whether the lock _was every dropped_ not whether it
> currently is... which is of course what the meaning always was, it's just that
> commit e24d552a17e9 ("mm/madvise: eliminate very confusing manipulation of prev
> VMA") messed this up.
>
> I'll send a fix.

Actually looks to be Nico's series - mm/khugepaged: unify khugepaged and
 madv_collapse with collapse_single_pmd() - that has the bug. Replying there.

Cheers, Lorenzo