From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F295126B098 for ; Tue, 31 Mar 2026 11:54:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774958087; cv=none; b=CZUKW9svEoL66Eb1gHQAdO8SndqidqtncluiByuqq55ujN8yASq2sRYtnHDQwvBML78U3hlG7CIZf40S8kwSU2d2neXXxJEXNNnTysKDJbNzCBsBDbO0//2uxJpG1YR6ZHlplkuqfkb237bMOc60IglitoMueWkjtyFbrTu+ea4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774958087; c=relaxed/simple; bh=FzISalReozoKQskTO3BDtGFo/1VITHJsufTvE9+sOiw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WhalVUldZGriDOyYHcF7T585UwpoZWdV3nAt4Bu4FjHOaQsQw4lMT1l5DhSJXSDupXce6Ff1PvNYMnOXPH6flNWWyjbqcWQblrV8Tz3J3bIJvm5DdI13VL1/Nqv0aCrRMPao0SQPrGNIgRE9G+lYH9eQy8Wwk1vZR8aDaXLa+9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E/UV/KFI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E/UV/KFI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DEFFC19423; Tue, 31 Mar 2026 11:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774958086; bh=FzISalReozoKQskTO3BDtGFo/1VITHJsufTvE9+sOiw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E/UV/KFIwhLTtS83HrDWmyggFL9XDJYa6o3F0Kq+BU4ZrFehRRxvawW2ZX6K9Wdan 8F4IZv3vy2GK3G1rS5XbPgE/rY6FO8RQ+LeAlrSMEmDnDz2neUT/rw+7u1OBZKh/ll KhtusUIVOy7ckpowwHEysOUjYSDvpHWhy3rPwLCQHOmG02DQTWRrwoizsk7sYSK+zY SDVw534N8x6wRWjUbm3HNW2nT77y3j+F2DUv2fruigM+iv9/ILsEbEUvl5BwfZD/Gi Avp4Ra0mkzDUCproxWP5GbsZO8ibBnBSd++jL8wGpiai26oquyXgSWQiz92Qvwofae uZqmn62p/A+Lg== Date: Tue, 31 Mar 2026 12:54:43 +0100 From: "Lorenzo Stoakes (Oracle)" To: syzbot Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org, david@kernel.org, jannh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, vbabka@kernel.org Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in madvise_walk_vmas Message-ID: <64b4e45a-bfd6-4bbe-8774-5fc80d0d2cf1@lucifer.local> References: <69cb8ed0.050a0220.183828.0027.GAE@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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@syzkaller.appspotmail.com > > > > ================================================================== > > 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