Re: WARNING in __do_kernel_fault
From: Dmitry Vyukov <dvyukov@google.com>
Date: 2021-01-27 19:47:56
Also in:
lkml
On Wed, Jan 27, 2021 at 8:16 PM 'Andrey Konovalov' via syzkaller-bugs [off-list ref] wrote:
On Wed, Jan 27, 2021 at 7:57 PM Dmitry Vyukov [off-list ref] wrote:quoted
On Wed, Jan 27, 2021 at 7:46 PM 'Andrey Konovalov' via syzkaller-bugs [off-list ref] wrote:quoted
On Wed, Jan 27, 2021 at 6:24 PM Dmitry Vyukov [off-list ref] wrote:quoted
On Wed, Jan 27, 2021 at 6:15 PM Will Deacon [off-list ref] wrote:quoted
On Wed, Jan 27, 2021 at 06:00:30PM +0100, Dmitry Vyukov wrote:quoted
On Wed, Jan 27, 2021 at 5:56 PM syzbot [off-list ref] wrote:quoted
Hello, syzbot found the following issue on: HEAD commit: 2ab38c17 mailmap: remove the "repo-abbrev" comment git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15a25264d00000 kernel config: https://syzkaller.appspot.com/x/.config?x=ad43be24faf1194c dashboard link: https://syzkaller.appspot.com/bug?extid=45b6fce29ff97069e2c5 userspace arch: arm64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+45b6fce29ff97069e2c5@syzkaller.appspotmail.comThis happens on arm64 instance with mte enabled. There is a GPF in reiserfs_xattr_init on x86_64 reported: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde so I would assume it's just a plain NULL deref. Is this WARNING not indicative of a kernel bug? Or there is something special about this particular NULL deref?Congratulations, you're the first person to trigger this warning! This fires if we take an unexpected data abort in the kernel but when we get into the fault handler the page-table looks ok (according to the CPU via an 'AT' instruction). Are you using QEMU system emulation? Perhaps its handling of AT isn't quite right.Hi Will, Yes, it's qemu-system-aarch64 5.2 with -machine virt,mte=on -cpu max. Do you see any way forward for this issue? Can somehow prove/disprove it's qemu at fault?I've reproduced this crash (by taking [1] and changing sys_memfd_create to 279), but it manifests as a normal null-ptr-deref for me. I'm using the latest QEMU master. Which QEMU does syzbot use exactly?qemu-system-aarch64 5.2 from this container: https://github.com/google/syzkaller/blob/master/tools/docker/syzbot/Dockerfile you can get a prebuilt version with: docker pull gcr.io/syzkaller/syzbotReproduced with this QEMU, still a normal null-ptr-deref. Where do I find the full list of arguments that are passed to QEMU on syzbot?
I am yet to document all details of these new instances, but the syzkaller config contains: "qemu_args": "-machine virt,virtualization=on,mte=on,graphics=on,usb=on -cpu max" the rest are in vm/qemu/qemu.go _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel