Re: general protection fault in syscall_return_slowpath

[Dmitry Vyukov <dvyukov@google.com>]

On Tue, Mar 10, 2020 at 7:15 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Mon, Mar 09, 2020 at 09:20:58AM +0100, Dmitry Vyukov wrote:
> > On Sun, Mar 8, 2020 at 7:35 PM 'Jann Horn' via syzkaller-bugs
> > <syzkaller-bugs@googlegroups.com> wrote:
> > >
> > > On Sun, Mar 8, 2020 at 5:40 PM syzbot
> > > <syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> > > > HEAD commit:    63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16cfeac3e00000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=cd66e43794b178bb5cd6
> > > > compiler:       clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12a42329e00000
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com
> > > >
> > > > general protection fault, probably for non-canonical address 0x1ffffffff1255a6b: 0000 [#1] PREEMPT SMP KASAN
> > > > CPU: 0 PID: 8742 Comm: syz-executor.2 Not tainted 5.6.0-rc3-syzkaller #0
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > > RIP: 0010:arch_local_irq_disable arch/x86/include/asm/paravirt.h:757 [inline]
> > > > RIP: 0010:syscall_return_slowpath+0xeb/0x4a0 arch/x86/entry/common.c:277
> > > > Code: 00 10 0f 85 de 00 00 00 e8 b2 a3 76 00 48 c7 c0 58 d3 2a 89 48 c1 e8 03 80 3c 18 00 74 0c 48 c7 c7 58 d3 2a 89 e8 05 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > RSP: 0018:ffffc900020a7ed0 EFLAGS: 00010246
> > > > RAX: 1ffffffff1255a6b RBX: dffffc0000000000 RCX: ffff88808c512380
> > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > > > RBP: ffffc900020a7f10 R08: ffffffff810075bb R09: fffffbfff14d9182
> > > > R10: fffffbfff14d9182 R11: 0000000000000000 R12: 1ffff110118a2470
> > > > R13: 0000000000004000 R14: ffff88808c512380 R15: ffff88808c512380
> > > > FS:  000000000154f940(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000
> > > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > CR2: 000000000076c000 CR3: 00000000a6b05000 CR4: 00000000001406f0
> > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > > Call Trace:
> > > >  do_syscall_64+0x11f/0x1c0 arch/x86/entry/common.c:304
> > > >  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > BUG: kernel NULL pointer dereference, address: 0000000000000000
> > > > #PF: supervisor write access in kernel mode
> > > > #PF: error_code(0x0002) - not-present page
> > > > PGD 8fecc067 P4D 8fecc067 PUD 97953067 PMD 0
> > > > Oops: 0002 [#2] PREEMPT SMP KASAN
> > > > CPU: 0 PID: 8742 Comm: syz-executor.2 Not tainted 5.6.0-rc3-syzkaller #0
> > >
> > > Ugh, why does it build with -Werror...
>
> There are certain warnings that are specifically treated like errors:
>
> In the main Makefile:
>
> KBUILD_CFLAGS   += $(call cc-option,-Werror=incompatible-pointer-types)
>
> > Now I am realizing I don't know what's the proper way to turn off
> > warnings entirely...
> >
> > We turn off this CONFIG_ERROR_ON_WARNING historically:
> > https://github.com/google/syzkaller/blob/2e9971bbbfb4df6ba0118353163a7703f3dbd6ec/dashboard/config/bits-syzbot.config#L17
> > and I thought that's enough. But now I realize it's not even a thing.
> > I see it referenced in some ChromeOS threads and there are some
> > discussions re upstreaming, but apparently it never existed upstream.
> >
> > make has W=n, but it seems that it can only be used to produce more
> > warnings. We don't pass W=3 specifically and there is no W=0.
> >
> > Should we always build with CFLAGS=-w? Is it guaranteed to work? Or is
> > there a better way?
>
> Would passing -Wno-werror via KCFLAGS work? Otherwise, passing
> -Wno-error=<specific warning> should work.
>
> Cheers,
> Nathan

Filed https://github.com/google/syzkaller/issues/1635 so that this is not lost.