linux-kernel - Re: [syzbot] [mm?] WARNING in vma_merge_existing

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: <3b9b3626-0368-4381-ad01-e2c8fc9b873a@lucifer.local>
Date: Tue, 7 Jan 2025 10:15:23 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Aleksandr Nogikh <nogikh@...gle.com>,
        syzbot <syzbot+46423ed8fa1f1148c6e4@...kaller.appspotmail.com>,
        Liam.Howlett@...cle.com, akpm@...ux-foundation.org, jannh@...gle.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        syzkaller-bugs@...glegroups.com, vbabka@...e.cz
Subject: Re: [syzbot] [mm?] WARNING in vma_merge_existing_range

On Tue, Jan 07, 2025 at 09:14:54AM +0100, Dmitry Vyukov wrote:
> On Thu, 2 Jan 2025 at 18:19, 'Aleksandr Nogikh' via syzkaller-bugs
> <syzkaller-bugs@...glegroups.com> wrote:
> >
> > On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs
> > <syzkaller-bugs@...glegroups.com> wrote:
> > >
> > > Happy new year!
> >
> > Happy New Year! :)
> >
> > >
> > > On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel...
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4
> > > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > > userspace arch: i386
> > >
> > > Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit
> > > userland, 64-bit kernel?
> >
> > Yes, that's a 32-bit userspace binary running on a 64-bit kernel.
> >
> > >
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > Hmm. Racey thing?
> > >
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+46423ed8fa1f1148c6e4@...kaller.appspotmail.com
> > > >
> > > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
> > > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > > >  </TASK>
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734
> > >
> > > It'd be nice if syzbot could actually print the code that generates the
> > > warning :) a nice-to-have perhaps.
> >
> > Thanks for the suggestion!
> > I've filed https://github.com/google/syzkaller/issues/5654
>
> It may be better for the kernel to do it. Then it would benefit all
> testing systems, and most manual testing/reports as well.
> Since WARN_ON is a macro, it should be trivial to capture the
> condition string. I guess some embed kernels will want to turn it off,
> so probably should be configurable.

Well, you guys already print the userland portion right? It's not exactly
an area of the kernel I'd like to fiddle with because these splats are
output in unstable conditions and are probably best limited to outputting
minimal information rather than trying to do the computation involved in
disassembly.

I think in any case you've misinterpreted :) so what I'm saying here is
disassembly, you seem to be suggesting the __stringify(cond) thing, which
actually I have now added in this case anyway [0], along with a whole host
of other debug information.

This means next time a non-repro case like this occurs in merge code we'll
have a LOT more to go on.

[0]:https://lore.kernel.org/linux-mm/cover.1735932169.git.lorenzo.stoakes@oracle.com/