linux-kernel - Re: general protection fault in syscall_return

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+Ym3Pc-UO3X33AhFE1rbdmr1gHcEmzJjtX7YZaBb2qexg@mail.gmail.com>
Date:   Sun, 14 Jun 2020 10:03:16 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     syzkaller <syzkaller@...glegroups.com>,
        syzbot <syzbot+cd66e43794b178bb5cd6@...kaller.appspotmail.com>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: general protection fault in syscall_return_slowpath

On Tue, Mar 10, 2020 at 9:10 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Tue, Mar 10, 2020 at 7:15 AM Nathan Chancellor
> <natechancellor@...il.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@...glegroups.com> wrote:
> > > >
> > > > On Sun, Mar 8, 2020 at 5:40 PM syzbot
> > > > <syzbot+cd66e43794b178bb5cd6@...kaller.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@...kaller.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.

Jann,

Getting back to this.
Are you sure building without warning will be better?

Currently make enables these warnings as errors only:

-Werror=strict-prototypes
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=date-time
-Werror=incompatible-pointer-types
-Werror=designated-init

So most warnings won't cause build failure.
And, say, converting T* to Y* implicitly may be an actual bug in the patch.

The other concern is that some people may use syzbot testing as the
only patch testing and then submit a patch that breaks build...