Re: WARNING in __do_kernel_fault

[Will Deacon]

On Wed, Jan 27, 2021 at 06:00:30PM +0100, Dmitry Vyukov wrote:
> On Wed, Jan 27, 2021 at 5:56 PM syzbot
> <syzbot+45b6fce29ff97069e2c5@xxxxxxxxxxxxxxxxxxxxxxxxx> 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: syzbot+45b6fce29ff97069e2c5@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> 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.

Will