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: [email protected]
REISERFS (device loop0): Using rupasov hash to sort names
------------[ cut here ]------------
Ignoring spurious kernel translation fault at virtual address 0000000000000030
WARNING: CPU: 1 PID: 5380 at arch/arm64/mm/fault.c:364 __do_kernel_fault+0x198/0x1c0 arch/arm64/mm/fault.c:364
Modules linked in:
CPU: 1 PID: 5380 Comm: syz-executor.0 Not tainted 5.11.0-rc5-syzkaller-00037-g2ab38c17aac1 #0
Hardware name: linux,dummy-virt (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
pc : __do_kernel_fault+0x198/0x1c0 arch/arm64/mm/fault.c:364
lr : __do_kernel_fault+0x198/0x1c0 arch/arm64/mm/fault.c:364
sp : ffff800014933830
x29: ffff800014933830 x28: f1ff00000c28bc00
x27: ffff80001231db80 x26: f0ff00002054a0b8
x25: 0000000000000000 x24: f1ff000004217680
x23: 0000000097c78006 x22: 0000000000000030
x21: 0000000000000025 x20: ffff800014933960
x19: 0000000097c78006 x18: 00000000fffffffb
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000020 x14: 6c656e72656b2073
x13: 00000000000006f9 x12: ffff8000149334e0
x11: ffff80001313b450 x10: 00000000ffffe000
x9 : ffff80001313b450 x8 : ffff80001308b450
x7 : ffff80001313b450 x6 : 0000000000000000
x5 : ffff00007fbe1948 x4 : 0000000000015ff5
x3 : 0000000000000001 x2 : 0000000000000000
x1 : 0000000000000000 x0 : f1ff00000c28bc00
Call trace:
__do_kernel_fault+0x198/0x1c0 arch/arm64/mm/fault.c:364
do_page_fault+0x1c0/0x3a0 arch/arm64/mm/fault.c:649
do_translation_fault+0xb4/0xc4 arch/arm64/mm/fault.c:660
do_mem_abort+0x44/0xbc arch/arm64/mm/fault.c:793
el1_abort+0x40/0x6c arch/arm64/kernel/entry-common.c:118
el1_sync_handler+0xb0/0xcc arch/arm64/kernel/entry-common.c:209
el1_sync+0x70/0x100 arch/arm64/kernel/entry.S:656
reiserfs_xattr_jcreate_nblocks fs/reiserfs/xattr.h:79 [inline]
reiserfs_security_init+0x98/0x10c fs/reiserfs/xattr_security.c:70
reiserfs_mkdir+0xf4/0x320 fs/reiserfs/namei.c:821
xattr_mkdir.constprop.0+0x24/0x3c fs/reiserfs/xattr.c:76
create_privroot fs/reiserfs/xattr.c:889 [inline]
reiserfs_xattr_init+0x16c/0x320 fs/reiserfs/xattr.c:1011
reiserfs_fill_super+0xa34/0xd20 fs/reiserfs/super.c:2177
mount_bdev+0x1c4/0x1f0 fs/super.c:1366
get_super_block+0x1c/0x30 fs/reiserfs/super.c:2606
legacy_get_tree+0x34/0x64 fs/fs_context.c:592
vfs_get_tree+0x2c/0xf0 fs/super.c:1496
do_new_mount fs/namespace.c:2881 [inline]
path_mount+0x3e8/0xaf0 fs/namespace.c:3211
do_mount fs/namespace.c:3224 [inline]
__do_sys_mount fs/namespace.c:3432 [inline]
__se_sys_mount fs/namespace.c:3409 [inline]
__arm64_sys_mount+0x1a8/0x2fc fs/namespace.c:3409
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
el0_svc_common.constprop.0+0x74/0x190 arch/arm64/kernel/syscall.c:159
do_el0_svc+0x78/0x90 arch/arm64/kernel/syscall.c:198
el0_svc+0x14/0x20 arch/arm64/kernel/entry-common.c:365
el0_sync_handler+0x1a8/0x1b0 arch/arm64/kernel/entry-common.c:381
el0_sync+0x190/0x1c0 arch/arm64/kernel/entry.S:699
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Wed, Jan 27, 2021 at 7:57 PM Dmitry Vyukov <[email protected]> wrote:
>
> On Wed, Jan 27, 2021 at 7:46 PM 'Andrey Konovalov' via syzkaller-bugs
> <[email protected]> wrote:
> >
> > On Wed, Jan 27, 2021 at 6:24 PM Dmitry Vyukov <[email protected]> wrote:
> > >
> > > On Wed, Jan 27, 2021 at 6:15 PM Will Deacon <[email protected]> wrote:
> > > >
> > > > On Wed, Jan 27, 2021 at 06:00:30PM +0100, Dmitry Vyukov wrote:
> > > > > On Wed, Jan 27, 2021 at 5:56 PM syzbot
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > 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: [email protected]
> > > > >
> > > > > This 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/syzbot
Reproduced 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?
On Wed, Jan 27, 2021 at 8:43 PM Dmitry Vyukov <[email protected]> wrote:
> > > > > > > This 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/syzbot
> >
> > Reproduced 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
OK, the virtualization=on part is what causes this. Bug in QEMU?
On Wed, Jan 27, 2021 at 8:16 PM 'Andrey Konovalov' via syzkaller-bugs
<[email protected]> wrote:
>
> On Wed, Jan 27, 2021 at 7:57 PM Dmitry Vyukov <[email protected]> wrote:
> >
> > On Wed, Jan 27, 2021 at 7:46 PM 'Andrey Konovalov' via syzkaller-bugs
> > <[email protected]> wrote:
> > >
> > > On Wed, Jan 27, 2021 at 6:24 PM Dmitry Vyukov <[email protected]> wrote:
> > > >
> > > > On Wed, Jan 27, 2021 at 6:15 PM Will Deacon <[email protected]> wrote:
> > > > >
> > > > > On Wed, Jan 27, 2021 at 06:00:30PM +0100, Dmitry Vyukov wrote:
> > > > > > On Wed, Jan 27, 2021 at 5:56 PM syzbot
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > 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: [email protected]
> > > > > >
> > > > > > This 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/syzbot
>
> Reproduced 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