linux-kernel - Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in do_sync_mmap

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: <29624f1e-de4f-492d-b54c-bb99f58b582f@arm.com>
Date: Thu, 19 Jun 2025 13:29:45 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: Will Deacon <will@...nel.org>
Cc: Jan Kara <jack@...e.cz>, akpm@...ux-foundation.org, david@...hat.com,
 jgg@...pe.ca, jhubbard@...dia.com, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, peterx@...hat.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in
 do_sync_mmap_readahead

On 19/06/2025 13:21, Will Deacon wrote:
> On Thu, Jun 19, 2025 at 11:57:05AM +0100, Ryan Roberts wrote:
>> On 19/06/2025 10:52, Jan Kara wrote:
>>> Hi,
>>>
>>> On Wed 18-06-25 05:56:30, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit:    bc6e0ba6c9ba Add linux-next specific files for 20250613
>>>> git tree:       linux-next
>>>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=108c710c580000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=2f7a2e4d17ed458f
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=8e4be574cb8c40140a2a
>>>> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=148c710c580000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=179025d4580000
>>>>
>>>> Downloadable assets:
>>>> disk image: https://storage.googleapis.com/syzbot-assets/2430bb0465cc/disk-bc6e0ba6.raw.xz
>>>> vmlinux: https://storage.googleapis.com/syzbot-assets/436a39deef0a/vmlinux-bc6e0ba6.xz
>>>> kernel image: https://storage.googleapis.com/syzbot-assets/e314ca5b1eb3/bzImage-bc6e0ba6.xz
>>>>
>>>> The issue was bisected to:
>>>>
>>>> commit 3b61a3f08949297815b2c77ae2696f54cd339419
>>>> Author: Ryan Roberts <ryan.roberts@....com>
>>>> Date:   Mon Jun 9 09:27:27 2025 +0000
>>>>
>>>>     mm/filemap: allow arch to request folio size for exec memory
>>>
>>> Indeed. The crash is in:
>>>
>>> 	fpin = maybe_unlock_mmap_for_io(vmf, fpin);
>>> 	if (vm_flags & VM_EXEC) {
>>> 		/*
>>> 		 * Allow arch to request a preferred minimum folio order for
>>> 		 * executable memory. This can often be beneficial to
>>> 		 * performance if (e.g.) arm64 can contpte-map the folio.
>>> 		 * Executable memory rarely benefits from readahead, due to its
>>> 		 * random access nature, so set async_size to 0.
>>> 		 *
>>> 		 * Limit to the boundaries of the VMA to avoid reading in any
>>> 		 * pad that might exist between sections, which would be a waste
>>> 		 * of memory.
>>> 		 */
>>> 		struct vm_area_struct *vma = vmf->vma;
>>> 		unsigned long start = vma->vm_pgoff;
>>> 				^^^^ here
>>> which is not surprising because we've unlocked mmap_sem (or vma lock) just
>>> above this if and thus vma could have been released before we got here. The
>>> easiest fix is to move maybe_unlock_mmap_for_io() below this if. There's
>>> nothing in there that would be problematic with the locks still held.
>>
>> Thanks for the quick analysis, Jan! Ouch...
>>
>> This is still in mm-unstable I believe, so I'll send a fix-up patch to Andrew to
>> move the unlock as you suggest.
>>
>> By the way, I don't think I was included on the original report; Is there a way
>> I can sign up to be included on patched I authored in future?
> 
> Your address looks like it's on To:
> 
> https://lore.kernel.org/r/6852b77e.a70a0220.79d0a.0214.GAE@google.com
> 
> but maybe you redirect syzbot reports to the SP^H^HIMPORTANT folder?

Hmm... Another email fail from me I guess. I don't have any rule that I'm aware
of and I don't see it in any of the folders that I do redirect to, nor in the
trash. Anyway, it's almost certainly my error. Thanks for pointing it out.

> 
> Will