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: <b7jh32d5xgliuohzkbebyjegtwj44qjfkxnez7lv2cooe3nnds@gw67fqr7jlin>
Date: Mon, 18 Nov 2024 10:38:07 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Aleksandr Nogikh <nogikh@...gle.com>,
        syzbot <syzbot+bc6bfc25a68b7a020ee1@...kaller.appspotmail.com>,
        akpm@...ux-foundation.org, jannh@...gle.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        lorenzo.stoakes@...cle.com, syzkaller-bugs@...glegroups.com,
        vbabka@...e.cz
Subject: Re: [syzbot] [mm?] general protection fault in mas_store_prealloc

* Liam R. Howlett <Liam.Howlett@...cle.com> [241118 10:21]:
> * Aleksandr Nogikh <nogikh@...gle.com> [241118 08:13]:
> > Hi Liam,
> > 
> > On Mon, Nov 18, 2024 at 3:49 AM 'Liam R. Howlett' via syzkaller-bugs
> > <syzkaller-bugs@...glegroups.com> wrote:
> > >
> > > * syzbot <syzbot+bc6bfc25a68b7a020ee1@...kaller.appspotmail.com> [241117 05:42]:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    8e9a54d7181b Merge remote-tracking branch 'iommu/arm/smmu'..
> > > > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=17b0ace8580000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a1eb85a42cb8ccec
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=bc6bfc25a68b7a020ee1
> > > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > > userspace arch: arm64
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=147521a7980000
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=102e14c0580000
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/ad658fb4d0a2/disk-8e9a54d7.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/1b7754fa8c67/vmlinux-8e9a54d7.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/50315382fefb/Image-8e9a54d7.gz.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+bc6bfc25a68b7a020ee1@...kaller.appspotmail.com
> > >
> > > I was unable to get this reproducer to work on my own image, even using
> > > the config and compiler specified in the report.  The injection was not
> > > happening at the same location as the crash reports.

One other point that could have helped find the issue faster (although
I was able to find it pretty fast with your tools already), would be to
include the injection portion in the email.  I was able to find it in
the logs on the dashboard and in my own testing, but if it was included
in the email it'd be nice.

> > >
> > > After using the provided disk (which was tricky), I was able to get it
> > > to work.
> > 
> > Just in case: did you follow the official syzbot instructions on
> > reproducing the bugs from the attached assets? [1] If yes, what extra
> > information could have made the process simpler for you?
> > 
> > [1] https://github.com/google/syzkaller/blob/master/docs/syzbot_assets.md
> 
> The instructions on getting the source we need (without adding yet
> another remote and fetching the entire repo) would help, as well as
> booting the kernel.
> 
> ie: --kernel <file> --append <root=...>
> 
> The missing part for me was that the commit listed was already gone, so
> after Lorenzo responded and restested with code in the repo, I could
> pull the kernel.  Maybe I could have just fetched the ref somehow?
> 
> So these instructions are good.  I didn't see them in the emails or on
> the dashboard though?
> 
> Booting my own kernel ended up in panics about the rootfs missing, and
> some fool around with that.
> 
> > 
> > > Booting was painfully slow, and makes me wonder if there is a
> > > better way for reproducing issues in the future.
> > 
> > I guess that unless you run it on an arm64 device with a nested
> > virtualization support, this bug's reproduction will be slow anyway :(
> 
> The initial boot of arm64 seems to just sit around for a while thinking
> about booting.  My installed vm was using uefi, which turned out to also
> be a pain point.
> 
> > 
> > If you recompile the kernel image without CONFIG_KASAN and
> > CONFIG_KCOV, that should speed it up to some degree.
> 
> I think arm64 on amd64 is just slow, but thanks.  kasan seems necessary
> a lot of the time.
> 
> Regards,
> Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ