* Re: general protection fault in syscall_return_slowpath
2020-03-08 7:45 general protection fault in syscall_return_slowpath syzbot
@ 2020-03-08 16:13 ` Andy Lutomirski
2020-03-08 16:37 ` Borislav Petkov
2020-03-08 18:26 ` Thomas Gleixner
2020-03-08 16:29 ` Andy Lutomirski
` (3 subsequent siblings)
4 siblings, 2 replies; 20+ messages in thread
From: Andy Lutomirski @ 2020-03-08 16:13 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Borislav Petkov, H. Peter Anvin, LKML, Andrew Lutomirski,
Ingo Molnar, Thomas Gleixner, X86 ML
On Sat, Mar 7, 2020 at 11:45 PM syzbot
<syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> 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
I tried to reproduce this and got:
$ make -j4
tools/syz-env/env.go:14:2: cannot find package
"github.com/google/syzkaller/pkg/osutil" in any of:
I'm sure that if I actually understood Go's delightful packaging
system, I could reverse engineer your build system and figure out how
to make it work. But perhaps you could document the build process?
Or maybe make 'make' just work?
For kicks, I tried this:
$ mkdir -p src/github.com/google
$ ln -sr . src/github.com/google/syzkaller
$ GOPATH=`/bin/pwd` make
GOOS=linux GOARCH=amd64 go install ./syz-manager
go install: no install location for directory
/home/luto/apps/syzkaller/syz-manager outside GOPATH
Are there instructions for just building syzkaller? I don't want to
install it, I don't want to fuzz my kernel -- I just want to run your
reproducer.
--Andy
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 16:13 ` Andy Lutomirski
@ 2020-03-08 16:37 ` Borislav Petkov
2020-03-08 18:26 ` Thomas Gleixner
1 sibling, 0 replies; 20+ messages in thread
From: Borislav Petkov @ 2020-03-08 16:37 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Dmitry Vyukov, H. Peter Anvin, LKML, Ingo Molnar,
Thomas Gleixner, X86 ML
On Sun, Mar 08, 2020 at 09:13:45AM -0700, Andy Lutomirski wrote:
> Are there instructions for just building syzkaller? I don't want to
> install it, I don't want to fuzz my kernel -- I just want to run your
> reproducer.
+1.
It would be lovely if there were a bootstrapping script which I run
and which fetches all the required gunk for the reproducer to run and
eventually runs it too instead of me having to fiddle with setting up go
each time.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 16:13 ` Andy Lutomirski
2020-03-08 16:37 ` Borislav Petkov
@ 2020-03-08 18:26 ` Thomas Gleixner
2020-03-09 8:34 ` Dmitry Vyukov
2020-03-09 8:42 ` Dmitry Vyukov
1 sibling, 2 replies; 20+ messages in thread
From: Thomas Gleixner @ 2020-03-08 18:26 UTC (permalink / raw)
To: Andy Lutomirski, Dmitry Vyukov
Cc: Borislav Petkov, H. Peter Anvin, LKML, Andrew Lutomirski,
Ingo Molnar, X86 ML
Andy Lutomirski <luto@kernel.org> writes:
> On Sat, Mar 7, 2020 at 11:45 PM syzbot
> <syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> $ make -j4
> tools/syz-env/env.go:14:2: cannot find package
> "github.com/google/syzkaller/pkg/osutil" in any of:
>
> I'm sure that if I actually understood Go's delightful packaging
> system, I could reverse engineer your build system and figure out how
> to make it work. But perhaps you could document the build process?
> Or maybe make 'make' just work?
>
> For kicks, I tried this:
>
> $ mkdir -p src/github.com/google
> $ ln -sr . src/github.com/google/syzkaller
> $ GOPATH=`/bin/pwd` make
> GOOS=linux GOARCH=amd64 go install ./syz-manager
> go install: no install location for directory
> /home/luto/apps/syzkaller/syz-manager outside GOPATH
>
> Are there instructions for just building syzkaller? I don't want to
> install it, I don't want to fuzz my kernel -- I just want to run your
> reproducer.
https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
That's how I build the binaries:
mkdir foo
export GOPATH=$HOME/foo
cd foo
go get -u -d github.com/google/syzkaller/...
cd src/github.com/google/syzkaller
make
cp bin/linux_amd64/syz-execprog bin/linux_amd64/syz-executor $GOPATH
Of course you can build it somewhere and scp the executables to a test box.
And then to run it
cd $GOPATH
wget -O repro.syz https://syzkaller.appspot.com/x/repro.syz?x=12a42329e00000
./syz-execprog -procs 6 -repeat 0 -collide -disable none repro.syz
The command line options are a bit tedious as you have to look them up
in the comment in repro.syz.
A scripts which converts that comment into command line options or
syz-execprog simply taking it from repro.syz would indeed be handy.
A kernel with the config provided in the report and running that
reproducer is still not reproducing with a runtime of 8hrs+ :(
Thanks,
tglx
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 18:26 ` Thomas Gleixner
@ 2020-03-09 8:34 ` Dmitry Vyukov
2020-03-09 18:26 ` Eric Biggers
2020-03-09 8:42 ` Dmitry Vyukov
1 sibling, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2020-03-09 8:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Borislav Petkov, H. Peter Anvin, LKML, Andrew Lutomirski,
Ingo Molnar, X86 ML, Jann Horn, syzkaller-bugs
On Sun, Mar 8, 2020 at 7:26 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Andy Lutomirski <luto@kernel.org> writes:
> > On Sat, Mar 7, 2020 at 11:45 PM syzbot
> > <syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> > $ make -j4
> > tools/syz-env/env.go:14:2: cannot find package
> > "github.com/google/syzkaller/pkg/osutil" in any of:
> >
> > I'm sure that if I actually understood Go's delightful packaging
> > system, I could reverse engineer your build system and figure out how
> > to make it work. But perhaps you could document the build process?
> > Or maybe make 'make' just work?
> >
> > For kicks, I tried this:
> >
> > $ mkdir -p src/github.com/google
> > $ ln -sr . src/github.com/google/syzkaller
> > $ GOPATH=`/bin/pwd` make
> > GOOS=linux GOARCH=amd64 go install ./syz-manager
> > go install: no install location for directory
> > /home/luto/apps/syzkaller/syz-manager outside GOPATH
> >
> > Are there instructions for just building syzkaller? I don't want to
> > install it, I don't want to fuzz my kernel -- I just want to run your
> > reproducer.
>
> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
>
> That's how I build the binaries:
>
> mkdir foo
> export GOPATH=$HOME/foo
>
> cd foo
> go get -u -d github.com/google/syzkaller/...
> cd src/github.com/google/syzkaller
> make
> cp bin/linux_amd64/syz-execprog bin/linux_amd64/syz-executor $GOPATH
>
> Of course you can build it somewhere and scp the executables to a test box.
>
> And then to run it
>
> cd $GOPATH
> wget -O repro.syz https://syzkaller.appspot.com/x/repro.syz?x=12a42329e00000
> ./syz-execprog -procs 6 -repeat 0 -collide -disable none repro.syz
>
> The command line options are a bit tedious as you have to look them up
> in the comment in repro.syz.
>
> A scripts which converts that comment into command line options or
> syz-execprog simply taking it from repro.syz would indeed be handy.
>
> A kernel with the config provided in the report and running that
> reproducer is still not reproducing with a runtime of 8hrs+ :(
>
> Thanks,
>
> tglx
I see the repro opens /dev/fb0, so this may be related to the exact
type of framebuffer on the machine. That's what Jann tried to figure
out.
There is a plenty of open bugs on dashboard related to fb/tty, just
doing a quick grep based on titles:
https://syzkaller.appspot.com/upstream
BUG: unable to handle kernel paging request in
drm_fb_helper_dirty_work 7 4d20h 90d
BUG: unable to handle kernel paging request in vga16fb_imageblit 1 74d 73d
divide error in fbcon_switch C cause 141 3d15h 96d
general protection fault in fbcon_cursor C cause 12 13h48m 87d
general protection fault in fbcon_fb_blanked 3 88d 90d
general protection fault in fbcon_invert_region 1 49d 48d
general protection fault in fbcon_modechanged 3 89d 90d
INFO: task hung in do_fb_ioctl 6 36d 57d
INFO: task hung in fb_compat_ioctl 1 87d 87d
INFO: task hung in fb_open C cause 171 1h06m 96d
INFO: task hung in fb_release C cause 23 2d12h 77d
INFO: task hung in release_tty 3 6d16h 62d
INFO: task hung in tty_ldisc_hangup C cause 15 17d 92d
INFO: trying to register non-static key in hci_uart_tty_receive (2) 1 103d 99d
KASAN: global-out-of-bounds Read in fbcon_get_font C cause 19 7d06h 90d
KASAN: global-out-of-bounds Read in fb_pad_aligned_buffer C cause 5 4d22h 92d
KASAN: global-out-of-bounds Read in vga16fb_imageblit C cause 225 1d11h 96d
KASAN: slab-out-of-bounds Read in fbcon_get_font C cause 42 5d04h 96d
KASAN: slab-out-of-bounds Read in fb_pad_aligned_buffer 4 9d00h 48d
KASAN: slab-out-of-bounds Write in fbcon_scroll 1 75d 73d
KASAN: use-after-free Read in fbcon_cursor syz cause 3 41d 84d
KASAN: use-after-free Read in fb_mode_is_equal syz cause 70 5h49m 92d
KASAN: use-after-free Read in tty_open C cause 7 42d 96d
KASAN: use-after-free Write in release_tty C cause 544 4h01m 96d
KASAN: vmalloc-out-of-bounds Read in drm_fb_helper_dirty_work 1 80d 80d
KASAN: vmalloc-out-of-bounds Write in drm_fb_helper_dirty_work 2 64d 76d
KCSAN: data-race in echo_char / n_tty_receive_buf_common 11 21d 125d
KMSAN: kernel-infoleak in tty_compat_ioctl C 81 2h17m 14d
memory leak in tty_init_dev C 3 121d 192d
possible deadlock in n_tty_receive_buf_common C cause 585 1h18m 23d
possible deadlock in tty_port_close_start C cause 4 9d18h 25d
WARNING in dlfb_submit_urb/usb_submit_urb C 190 8d23h 251d
So if you don't see something obvious here, it may be not worth
spending more time until these, more obvious ones are fixed. This may
be a previous silent memory corruption that wasn't caught by KASAN.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-09 8:34 ` Dmitry Vyukov
@ 2020-03-09 18:26 ` Eric Biggers
2020-03-10 5:41 ` Dmitry Vyukov
0 siblings, 1 reply; 20+ messages in thread
From: Eric Biggers @ 2020-03-09 18:26 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Thomas Gleixner, Borislav Petkov, H. Peter Anvin, LKML,
Andrew Lutomirski, Ingo Molnar, X86 ML, Jann Horn,
syzkaller-bugs
On Mon, Mar 09, 2020 at 09:34:25AM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote:
>
> I see the repro opens /dev/fb0, so this may be related to the exact
> type of framebuffer on the machine. That's what Jann tried to figure
> out.
>
> There is a plenty of open bugs on dashboard related to fb/tty, just
> doing a quick grep based on titles:
>
> https://syzkaller.appspot.com/upstream
> BUG: unable to handle kernel paging request in
> drm_fb_helper_dirty_work 7 4d20h 90d
> BUG: unable to handle kernel paging request in vga16fb_imageblit 1 74d 73d
> divide error in fbcon_switch C cause 141 3d15h 96d
> general protection fault in fbcon_cursor C cause 12 13h48m 87d
> general protection fault in fbcon_fb_blanked 3 88d 90d
> general protection fault in fbcon_invert_region 1 49d 48d
> general protection fault in fbcon_modechanged 3 89d 90d
> INFO: task hung in do_fb_ioctl 6 36d 57d
> INFO: task hung in fb_compat_ioctl 1 87d 87d
> INFO: task hung in fb_open C cause 171 1h06m 96d
> INFO: task hung in fb_release C cause 23 2d12h 77d
> INFO: task hung in release_tty 3 6d16h 62d
> INFO: task hung in tty_ldisc_hangup C cause 15 17d 92d
> INFO: trying to register non-static key in hci_uart_tty_receive (2) 1 103d 99d
> KASAN: global-out-of-bounds Read in fbcon_get_font C cause 19 7d06h 90d
> KASAN: global-out-of-bounds Read in fb_pad_aligned_buffer C cause 5 4d22h 92d
> KASAN: global-out-of-bounds Read in vga16fb_imageblit C cause 225 1d11h 96d
> KASAN: slab-out-of-bounds Read in fbcon_get_font C cause 42 5d04h 96d
> KASAN: slab-out-of-bounds Read in fb_pad_aligned_buffer 4 9d00h 48d
> KASAN: slab-out-of-bounds Write in fbcon_scroll 1 75d 73d
> KASAN: use-after-free Read in fbcon_cursor syz cause 3 41d 84d
> KASAN: use-after-free Read in fb_mode_is_equal syz cause 70 5h49m 92d
> KASAN: use-after-free Read in tty_open C cause 7 42d 96d
> KASAN: use-after-free Write in release_tty C cause 544 4h01m 96d
> KASAN: vmalloc-out-of-bounds Read in drm_fb_helper_dirty_work 1 80d 80d
> KASAN: vmalloc-out-of-bounds Write in drm_fb_helper_dirty_work 2 64d 76d
> KCSAN: data-race in echo_char / n_tty_receive_buf_common 11 21d 125d
> KMSAN: kernel-infoleak in tty_compat_ioctl C 81 2h17m 14d
> memory leak in tty_init_dev C 3 121d 192d
> possible deadlock in n_tty_receive_buf_common C cause 585 1h18m 23d
> possible deadlock in tty_port_close_start C cause 4 9d18h 25d
> WARNING in dlfb_submit_urb/usb_submit_urb C 190 8d23h 251d
>
> So if you don't see something obvious here, it may be not worth
> spending more time until these, more obvious ones are fixed. This may
> be a previous silent memory corruption that wasn't caught by KASAN.
Yesterday I was looking at a similar bug
"general protection fault in do_con_write"
(https://syzkaller.appspot.com/bug?id=f82ab89451323208e343f4a8632014ef12b1252d).
It has a simple single-threaded reproducer at
https://syzkaller.appspot.com/text?tag=ReproC&x=169c4c81e00000 that just:
1. Calls FBIOPUT_VSCREENINFO on /dev/fb0
2. Opens /dev/tty20 and writes something to it
Presumably, to reproduce this you at least need some graphics hardware with a
corresponding framebuffer driver (to get /dev/fb0), as well as
CONFIG_FRAMEBUFFER_CONSOLE=y (so that the virtual console /dev/tty20 uses a
framebuffer console and not something else like a VGA text mode console).
However, when I tried to reproduce this locally in QEMU with the same kconfig
(https://syzkaller.appspot.com/text?tag=KernelConfig&x=31018567b8f0fc70) and
with graphics enabled (-vga std), it didn't work.
I then tried to reproduce on a Google Compute Engine VM with the exact same
kconfig, and it worked. I think the framebuffer driver in use was vga16fb.c.
It's odd because the same driver seems to be used in the QEMU case, and in both
cases the virtual consoles were bound to the framebuffer console.
I need to double-check all this though.
And yes, probably many of the above bugs have the same cause.
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-09 18:26 ` Eric Biggers
@ 2020-03-10 5:41 ` Dmitry Vyukov
0 siblings, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2020-03-10 5:41 UTC (permalink / raw)
To: Eric Biggers
Cc: Thomas Gleixner, Borislav Petkov, H. Peter Anvin, LKML,
Andrew Lutomirski, Ingo Molnar, X86 ML, Jann Horn,
syzkaller-bugs
On Mon, Mar 9, 2020 at 7:26 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Mon, Mar 09, 2020 at 09:34:25AM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> >
> > I see the repro opens /dev/fb0, so this may be related to the exact
> > type of framebuffer on the machine. That's what Jann tried to figure
> > out.
> >
> > There is a plenty of open bugs on dashboard related to fb/tty, just
> > doing a quick grep based on titles:
> >
> > https://syzkaller.appspot.com/upstream
> > BUG: unable to handle kernel paging request in
> > drm_fb_helper_dirty_work 7 4d20h 90d
> > BUG: unable to handle kernel paging request in vga16fb_imageblit 1 74d 73d
> > divide error in fbcon_switch C cause 141 3d15h 96d
> > general protection fault in fbcon_cursor C cause 12 13h48m 87d
> > general protection fault in fbcon_fb_blanked 3 88d 90d
> > general protection fault in fbcon_invert_region 1 49d 48d
> > general protection fault in fbcon_modechanged 3 89d 90d
> > INFO: task hung in do_fb_ioctl 6 36d 57d
> > INFO: task hung in fb_compat_ioctl 1 87d 87d
> > INFO: task hung in fb_open C cause 171 1h06m 96d
> > INFO: task hung in fb_release C cause 23 2d12h 77d
> > INFO: task hung in release_tty 3 6d16h 62d
> > INFO: task hung in tty_ldisc_hangup C cause 15 17d 92d
> > INFO: trying to register non-static key in hci_uart_tty_receive (2) 1 103d 99d
> > KASAN: global-out-of-bounds Read in fbcon_get_font C cause 19 7d06h 90d
> > KASAN: global-out-of-bounds Read in fb_pad_aligned_buffer C cause 5 4d22h 92d
> > KASAN: global-out-of-bounds Read in vga16fb_imageblit C cause 225 1d11h 96d
> > KASAN: slab-out-of-bounds Read in fbcon_get_font C cause 42 5d04h 96d
> > KASAN: slab-out-of-bounds Read in fb_pad_aligned_buffer 4 9d00h 48d
> > KASAN: slab-out-of-bounds Write in fbcon_scroll 1 75d 73d
> > KASAN: use-after-free Read in fbcon_cursor syz cause 3 41d 84d
> > KASAN: use-after-free Read in fb_mode_is_equal syz cause 70 5h49m 92d
> > KASAN: use-after-free Read in tty_open C cause 7 42d 96d
> > KASAN: use-after-free Write in release_tty C cause 544 4h01m 96d
> > KASAN: vmalloc-out-of-bounds Read in drm_fb_helper_dirty_work 1 80d 80d
> > KASAN: vmalloc-out-of-bounds Write in drm_fb_helper_dirty_work 2 64d 76d
> > KCSAN: data-race in echo_char / n_tty_receive_buf_common 11 21d 125d
> > KMSAN: kernel-infoleak in tty_compat_ioctl C 81 2h17m 14d
> > memory leak in tty_init_dev C 3 121d 192d
> > possible deadlock in n_tty_receive_buf_common C cause 585 1h18m 23d
> > possible deadlock in tty_port_close_start C cause 4 9d18h 25d
> > WARNING in dlfb_submit_urb/usb_submit_urb C 190 8d23h 251d
> >
> > So if you don't see something obvious here, it may be not worth
> > spending more time until these, more obvious ones are fixed. This may
> > be a previous silent memory corruption that wasn't caught by KASAN.
>
> Yesterday I was looking at a similar bug
> "general protection fault in do_con_write"
> (https://syzkaller.appspot.com/bug?id=f82ab89451323208e343f4a8632014ef12b1252d).
>
> It has a simple single-threaded reproducer at
> https://syzkaller.appspot.com/text?tag=ReproC&x=169c4c81e00000 that just:
>
> 1. Calls FBIOPUT_VSCREENINFO on /dev/fb0
> 2. Opens /dev/tty20 and writes something to it
>
> Presumably, to reproduce this you at least need some graphics hardware with a
> corresponding framebuffer driver (to get /dev/fb0), as well as
> CONFIG_FRAMEBUFFER_CONSOLE=y (so that the virtual console /dev/tty20 uses a
> framebuffer console and not something else like a VGA text mode console).
>
> However, when I tried to reproduce this locally in QEMU with the same kconfig
> (https://syzkaller.appspot.com/text?tag=KernelConfig&x=31018567b8f0fc70) and
> with graphics enabled (-vga std), it didn't work.
>
> I then tried to reproduce on a Google Compute Engine VM with the exact same
> kconfig, and it worked. I think the framebuffer driver in use was vga16fb.c.
> It's odd because the same driver seems to be used in the QEMU case, and in both
> cases the virtual consoles were bound to the framebuffer console.
>
> I need to double-check all this though.
>
> And yes, probably many of the above bugs have the same cause.
Interesting. If you manage to reproduce it (or at least figure out
"the closest" video driver), it would be useful to mention at:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
Currently we don't specify any -vga flag at all.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 18:26 ` Thomas Gleixner
2020-03-09 8:34 ` Dmitry Vyukov
@ 2020-03-09 8:42 ` Dmitry Vyukov
1 sibling, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2020-03-09 8:42 UTC (permalink / raw)
To: Thomas Gleixner, syzkaller, syzkaller-bugs
Cc: Borislav Petkov, H. Peter Anvin, LKML, Andrew Lutomirski,
Ingo Molnar, X86 ML
On Sun, Mar 8, 2020 at 7:26 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Andy Lutomirski <luto@kernel.org> writes:
> > On Sat, Mar 7, 2020 at 11:45 PM syzbot
> > <syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> > $ make -j4
> > tools/syz-env/env.go:14:2: cannot find package
> > "github.com/google/syzkaller/pkg/osutil" in any of:
> >
> > I'm sure that if I actually understood Go's delightful packaging
> > system, I could reverse engineer your build system and figure out how
> > to make it work. But perhaps you could document the build process?
> > Or maybe make 'make' just work?
> >
> > For kicks, I tried this:
> >
> > $ mkdir -p src/github.com/google
> > $ ln -sr . src/github.com/google/syzkaller
> > $ GOPATH=`/bin/pwd` make
> > GOOS=linux GOARCH=amd64 go install ./syz-manager
> > go install: no install location for directory
> > /home/luto/apps/syzkaller/syz-manager outside GOPATH
> >
> > Are there instructions for just building syzkaller? I don't want to
> > install it, I don't want to fuzz my kernel -- I just want to run your
> > reproducer.
>
> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
>
> That's how I build the binaries:
>
> mkdir foo
> export GOPATH=$HOME/foo
>
> cd foo
> go get -u -d github.com/google/syzkaller/...
> cd src/github.com/google/syzkaller
> make
> cp bin/linux_amd64/syz-execprog bin/linux_amd64/syz-executor $GOPATH
>
> Of course you can build it somewhere and scp the executables to a test box.
>
> And then to run it
>
> cd $GOPATH
> wget -O repro.syz https://syzkaller.appspot.com/x/repro.syz?x=12a42329e00000
> ./syz-execprog -procs 6 -repeat 0 -collide -disable none repro.syz
>
> The command line options are a bit tedious as you have to look them up
> in the comment in repro.syz.
>
> A scripts which converts that comment into command line options or
> syz-execprog simply taking it from repro.syz would indeed be handy.
>
> A kernel with the config provided in the report and running that
> reproducer is still not reproducing with a runtime of 8hrs+ :(
There is https://github.com/google/syzkaller/issues/563 for a self
contained repro script.
But I am not sure how configurable it should be; how much should it
download; and if it should assume reproducing on host, or some other
remote machine/VM. Some users want only flags for syz-repro and have
the rest installed; some want the script to take care of Go toolchain
installation and/or syzkaller checkout; some also want
qemu/image/kernel/gcc. Some there is whole spectrum of what it can do
with lots of variations. If it does everything end-to-end downloading
tens of gigs and building own kernel, some users won't be happy. If we
add a gazillion of flags, one will need to be a certified expert in
configuring this script, which may be not simpler than doing all steps
manually, and obviously less transparent when it fails...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 7:45 general protection fault in syscall_return_slowpath syzbot
2020-03-08 16:13 ` Andy Lutomirski
@ 2020-03-08 16:29 ` Andy Lutomirski
2020-03-12 13:34 ` Dan Carpenter
2020-03-08 17:20 ` Jann Horn
` (2 subsequent siblings)
4 siblings, 1 reply; 20+ messages in thread
From: Andy Lutomirski @ 2020-03-08 16:29 UTC (permalink / raw)
To: syzbot
Cc: Borislav Petkov, H. Peter Anvin, LKML, Andrew Lutomirski,
Ingo Molnar, syzkaller-bugs, Thomas Gleixner, X86 ML
On Sat, Mar 7, 2020 at 11:45 PM syzbot
<syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> 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
>
I bet this is due to entirely missing input validation in
con_font_copy() and/or fbcon_copy_font().
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 16:29 ` Andy Lutomirski
@ 2020-03-12 13:34 ` Dan Carpenter
0 siblings, 0 replies; 20+ messages in thread
From: Dan Carpenter @ 2020-03-12 13:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: syzbot, Borislav Petkov, H. Peter Anvin, LKML, Ingo Molnar,
syzkaller-bugs, Thomas Gleixner, X86 ML
On Sun, Mar 08, 2020 at 09:29:04AM -0700, Andy Lutomirski wrote:
> On Sat, Mar 7, 2020 at 11:45 PM syzbot
> <syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > 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
> >
>
> I bet this is due to entirely missing input validation in
> con_font_copy() and/or fbcon_copy_font().
The only thing we use in con_font_copy() is op->height and we clamp it
to 0-MAX_NR_CONSOLES (64).
regards,
dan carpenter
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 7:45 general protection fault in syscall_return_slowpath syzbot
2020-03-08 16:13 ` Andy Lutomirski
2020-03-08 16:29 ` Andy Lutomirski
@ 2020-03-08 17:20 ` Jann Horn
2020-03-08 18:00 ` syzbot
2020-03-08 18:35 ` Jann Horn
2020-08-15 10:18 ` syzbot
4 siblings, 1 reply; 20+ messages in thread
From: Jann Horn @ 2020-03-08 17:20 UTC (permalink / raw)
To: syzbot
Cc: Borislav Petkov, H . Peter Anvin, kernel list, Andy Lutomirski,
Ingo Molnar, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]
On Sun, Mar 8, 2020 at 5:40 PM syzbot
<syzbot+cd66e43794b178bb5cd6@syzkaller.appspotmail.com> wrote:
> syzbot found the following crash on:
>
> 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
[...]
> 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
Let's see if we can get syzkaller to tell us which fbcon
implementation it's hitting...
#syz test: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
63623fd44972d1ed2bfb6e0fb631dfcf547fd1e7
[-- Attachment #2: 0001-FOR-TESTING-ONLY-tell-us-which-fbcon-implementation-.patch --]
[-- Type: text/x-patch, Size: 1194 bytes --]
From 8442144fe582ab38985378cf21ca88de1594b5df Mon Sep 17 00:00:00 2001
From: Jann Horn <jannh@google.com>
Date: Sun, 8 Mar 2020 18:15:11 +0100
Subject: [PATCH] FOR TESTING ONLY: tell us which fbcon implementation is used
---
drivers/tty/vt/vt.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 0cfbb7182b5a..b3dd44802208 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4590,7 +4590,7 @@ static int con_font_copy(struct vc_data *vc, struct console_font_op *op)
{
int con = op->height;
int rc;
-
+ static void *LAST;
console_lock();
if (vc->vc_mode != KD_TEXT)
@@ -4601,8 +4601,14 @@ static int con_font_copy(struct vc_data *vc, struct console_font_op *op)
rc = -ENOTTY;
else if (con == vc->vc_num) /* nothing to do */
rc = 0;
- else
+ else {
+ if (LAST != vc->vc_sw) {
+ pr_warn("con_font_copy(): vc_sw=%pS, vc_sw->con_font_copy=%pS\n",
+ vc->vc_sw, vc->vc_sw->con_font_copy);
+ LAST = vc->vc_sw;
+ }
rc = vc->vc_sw->con_font_copy(vc, con);
+ }
console_unlock();
return rc;
}
base-commit: 63623fd44972d1ed2bfb6e0fb631dfcf547fd1e7
--
2.25.1.481.gfbce0eb801-goog
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 17:20 ` Jann Horn
@ 2020-03-08 18:00 ` syzbot
0 siblings, 0 replies; 20+ messages in thread
From: syzbot @ 2020-03-08 18:00 UTC (permalink / raw)
To: bp, hpa, jannh, linux-kernel, luto, mingo, syzkaller-bugs, tglx, x86
Hello,
syzbot tried to test the proposed patch but build/boot failed:
e.o
CC fs/xfs/libxfs/xfs_refcount.o
CC fs/ceph/cache.o
CC fs/ocfs2/sysfile.o
CC fs/nfs/nfs4trace.o
CC fs/btrfs/extent_io.o
CC fs/btrfs/volumes.o
CC net/mac80211/mesh_sync.o
CC drivers/gpu/drm/drm_auth.o
CC fs/gfs2/recovery.o
CC fs/gfs2/rgrp.o
CC fs/btrfs/async-thread.o
CC drivers/gpu/drm/i915/gem/i915_gem_region.o
CC net/netfilter/xt_nat.o
CC fs/ocfs2/uptodate.o
AR net/vmw_vsock/built-in.a
CC fs/ocfs2/quota_local.o
CC fs/dcache.o
CC fs/inode.o
CC fs/afs/volume.o
CC fs/afs/write.o
CC fs/ceph/acl.o
CC fs/btrfs/ioctl.o
CC fs/btrfs/locking.o
CC fs/afs/xattr.o
CC net/netfilter/xt_AUDIT.o
CC fs/ocfs2/quota_global.o
CC fs/btrfs/orphan.o
CC fs/btrfs/export.o
CC net/netfilter/xt_CHECKSUM.o
CC fs/attr.o
CC net/netfilter/xt_CLASSIFY.o
CC drivers/gpu/drm/drm_cache.o
CC fs/bad_inode.o
CC fs/nfs/nfs4sysctl.o
CC drivers/gpu/drm/drm_file.o
CC fs/file.o
CC drivers/gpu/drm/i915/gem/i915_gem_shmem.o
CC drivers/gpu/drm/i915/gem/i915_gem_shrinker.o
CC drivers/gpu/drm/i915/gem/i915_gem_stolen.o
CC fs/gfs2/super.o
CC drivers/gpu/drm/i915/gem/i915_gem_throttle.o
CC fs/btrfs/tree-log.o
CC net/netfilter/xt_CONNSECMARK.o
CC fs/f2fs/xattr.o
CC fs/ocfs2/xattr.o
CC net/netfilter/xt_CT.o
CC net/mac80211/mesh_ps.o
CC fs/f2fs/acl.o
CC fs/filesystems.o
AR fs/erofs/built-in.a
CC fs/f2fs/verity.o
CC drivers/gpu/drm/drm_gem.o
CC fs/ocfs2/acl.o
CC fs/gfs2/sys.o
CC drivers/gpu/drm/drm_ioctl.o
CC fs/ocfs2/filecheck.o
CC fs/btrfs/free-space-cache.o
CC fs/namespace.o
CC drivers/gpu/drm/i915/gem/i915_gem_tiling.o
CC drivers/gpu/drm/drm_irq.o
CC fs/ocfs2/stack_o2cb.o
CC fs/ocfs2/stackglue.o
AR fs/ceph/built-in.a
CC drivers/gpu/drm/drm_memory.o
CC fs/btrfs/zlib.o
CC fs/btrfs/lzo.o
CC fs/nfs/pnfs.o
CC fs/gfs2/trans.o
CC fs/gfs2/util.o
CC fs/ocfs2/stack_user.o
CC fs/xfs/libxfs/xfs_refcount_btree.o
CC fs/xfs/libxfs/xfs_sb.o
CC net/netfilter/xt_DSCP.o
CC net/netfilter/xt_HL.o
CC drivers/gpu/drm/drm_drv.o
CC drivers/gpu/drm/drm_sysfs.o
CC fs/afs/yfsclient.o
CC fs/btrfs/zstd.o
CC fs/afs/proc.o
CC fs/f2fs/compress.o
CC fs/seq_file.o
CC fs/xattr.o
CC net/netfilter/xt_HMARK.o
CC net/mac80211/pm.o
CC drivers/gpu/drm/i915/gem/i915_gem_userptr.o
CC net/mac80211/rc80211_minstrel.o
CC net/mac80211/rc80211_minstrel_ht.o
CC fs/gfs2/lock_dlm.o
CC fs/nfs/pnfs_dev.o
CC fs/nfs/pnfs_nfs.o
CC fs/nfs/nfs42proc.o
CC fs/btrfs/compression.o
CC drivers/gpu/drm/i915/gem/i915_gem_wait.o
CC drivers/gpu/drm/i915/gem/i915_gemfs.o
CC net/mac80211/rc80211_minstrel_debugfs.o
CC net/mac80211/rc80211_minstrel_ht_debugfs.o
CC fs/btrfs/delayed-ref.o
CC drivers/gpu/drm/drm_hashtab.o
CC fs/xfs/libxfs/xfs_symlink_remote.o
CC fs/xfs/libxfs/xfs_trans_resv.o
CC net/netfilter/xt_LED.o
CC fs/xfs/libxfs/xfs_trans_inode.o
CC fs/xfs/libxfs/xfs_types.o
CC fs/btrfs/relocation.o
CC net/netfilter/xt_LOG.o
CC drivers/gpu/drm/drm_mm.o
CC net/netfilter/xt_NETMAP.o
CC net/netfilter/xt_NFLOG.o
CC net/netfilter/xt_NFQUEUE.o
CC net/netfilter/xt_RATEEST.o
CC drivers/gpu/drm/i915/i915_active.o
CC net/netfilter/xt_REDIRECT.o
CC fs/btrfs/delayed-inode.o
CC drivers/gpu/drm/i915/i915_buddy.o
CC fs/xfs/libxfs/xfs_rtbitmap.o
CC fs/btrfs/scrub.o
CC fs/libfs.o
CC drivers/gpu/drm/drm_crtc.o
CC drivers/gpu/drm/drm_fourcc.o
CC drivers/gpu/drm/drm_modes.o
CC drivers/gpu/drm/drm_edid.o
CC fs/fs-writeback.o
CC drivers/gpu/drm/i915/i915_cmd_parser.o
CC fs/pnode.o
CC fs/splice.o
CC drivers/gpu/drm/i915/i915_gem_evict.o
CC fs/sync.o
CC fs/utimes.o
CC fs/d_path.o
AR fs/gfs2/built-in.a
CC fs/xfs/xfs_aops.o
CC fs/xfs/xfs_attr_inactive.o
CC drivers/gpu/drm/i915/i915_gem_fence_reg.o
CC drivers/gpu/drm/i915/i915_gem_gtt.o
CC drivers/gpu/drm/i915/i915_gem.o
CC fs/btrfs/reada.o
CC fs/btrfs/backref.o
CC drivers/gpu/drm/drm_encoder_slave.o
CC drivers/gpu/drm/drm_trace_points.o
CC drivers/gpu/drm/drm_prime.o
CC drivers/gpu/drm/drm_rect.o
CC fs/stack.o
CC net/netfilter/xt_MASQUERADE.o
CC fs/xfs/xfs_attr_list.o
CC drivers/gpu/drm/drm_vma_manager.o
CC fs/xfs/xfs_bmap_util.o
CC fs/fs_struct.o
CC net/netfilter/xt_SECMARK.o
CC fs/xfs/xfs_bio_io.o
CC drivers/gpu/drm/i915/i915_globals.o
CC drivers/gpu/drm/i915/i915_query.o
CC fs/xfs/xfs_buf.o
CC fs/xfs/xfs_dir2_readdir.o
CC drivers/gpu/drm/i915/i915_request.o
CC drivers/gpu/drm/i915/i915_scheduler.o
CC drivers/gpu/drm/drm_flip_work.o
CC net/netfilter/xt_TPROXY.o
CC fs/statfs.o
CC fs/btrfs/ulist.o
CC drivers/gpu/drm/drm_modeset_lock.o
CC drivers/gpu/drm/drm_atomic.o
CC drivers/gpu/drm/drm_bridge.o
CC drivers/gpu/drm/drm_framebuffer.o
AR fs/afs/built-in.a
CC drivers/gpu/drm/drm_connector.o
CC drivers/gpu/drm/drm_blend.o
CC fs/xfs/xfs_discard.o
CC fs/fs_pin.o
CC drivers/gpu/drm/drm_encoder.o
CC fs/nsfs.o
CC drivers/gpu/drm/drm_mode_object.o
CC fs/fs_types.o
CC net/netfilter/xt_TCPMSS.o
CC fs/xfs/xfs_error.o
AR fs/f2fs/built-in.a
CC drivers/gpu/drm/drm_property.o
CC drivers/gpu/drm/i915/i915_trace_points.o
CC net/netfilter/xt_TCPOPTSTRIP.o
CC drivers/gpu/drm/i915/i915_vma.o
CC fs/btrfs/qgroup.o
CC fs/xfs/xfs_export.o
CC fs/xfs/xfs_extent_busy.o
CC drivers/gpu/drm/drm_plane.o
CC fs/fs_context.o
CC fs/fs_parser.o
CC fs/xfs/xfs_file.o
CC fs/btrfs/send.o
CC drivers/gpu/drm/drm_color_mgmt.o
CC fs/btrfs/dev-replace.o
CC drivers/gpu/drm/i915/intel_region_lmem.o
CC fs/buffer.o
CC fs/fsopen.o
CC fs/xfs/xfs_filestream.o
CC fs/xfs/xfs_fsmap.o
CC fs/block_dev.o
CC drivers/gpu/drm/i915/intel_wopcm.o
CC fs/btrfs/uuid-tree.o
CC fs/btrfs/raid56.o
CC drivers/gpu/drm/drm_print.o
CC fs/xfs/xfs_fsops.o
CC drivers/gpu/drm/i915/gt/uc/intel_uc.o
CC net/netfilter/xt_TEE.o
CC net/netfilter/xt_TRACE.o
CC net/netfilter/xt_IDLETIMER.o
CC net/netfilter/xt_addrtype.o
CC drivers/gpu/drm/drm_dumb_buffers.o
CC fs/direct-io.o
CC net/netfilter/xt_bpf.o
CC net/netfilter/xt_cluster.o
CC drivers/gpu/drm/drm_mode_config.o
CC fs/btrfs/props.o
CC fs/xfs/xfs_globals.o
CC drivers/gpu/drm/drm_vblank.o
AR net/mac80211/built-in.a
CC fs/xfs/xfs_health.o
CC drivers/gpu/drm/drm_syncobj.o
CC fs/mpage.o
CC fs/xfs/xfs_icache.o
CC drivers/gpu/drm/drm_lease.o
CC fs/proc_namespace.o
CC fs/btrfs/free-space-tree.o
CC drivers/gpu/drm/i915/gt/uc/intel_uc_fw.o
CC fs/eventpoll.o
CC fs/anon_inodes.o
CC fs/signalfd.o
CC fs/btrfs/tree-checker.o
CC fs/btrfs/space-info.o
CC fs/xfs/xfs_ioctl.o
CC fs/xfs/xfs_iomap.o
CC drivers/gpu/drm/drm_writeback.o
CC fs/btrfs/block-rsv.o
CC fs/xfs/xfs_iops.o
CC drivers/gpu/drm/drm_client.o
CC fs/xfs/xfs_inode.o
CC drivers/gpu/drm/drm_client_modeset.o
CC fs/xfs/xfs_itable.o
CC fs/btrfs/delalloc-space.o
CC drivers/gpu/drm/drm_atomic_uapi.o
CC net/netfilter/xt_comment.o
CC drivers/gpu/drm/drm_hdcp.o
CC net/netfilter/xt_connbytes.o
CC fs/xfs/xfs_iwalk.o
AR fs/nfs/built-in.a
CC drivers/gpu/drm/i915/gt/uc/intel_guc.o
CC drivers/gpu/drm/drm_ioc32.o
CC fs/btrfs/block-group.o
CC net/netfilter/xt_connlabel.o
CC fs/timerfd.o
CC net/netfilter/xt_connlimit.o
CC fs/xfs/xfs_message.o
CC fs/btrfs/discard.o
CC fs/btrfs/acl.o
CC drivers/gpu/drm/drm_gem_shmem_helper.o
CC fs/xfs/xfs_mount.o
CC fs/eventfd.o
CC drivers/gpu/drm/drm_panel.o
CC net/netfilter/xt_conntrack.o
CC drivers/gpu/drm/drm_agpsupport.o
CC fs/userfaultfd.o
CC net/netfilter/xt_cpu.o
CC net/netfilter/xt_devgroup.o
CC net/netfilter/xt_dccp.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_ads.o
CC net/netfilter/xt_dscp.o
CC fs/aio.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_ct.o
CC fs/xfs/xfs_mru_cache.o
CC fs/io_uring.o
CC drivers/gpu/drm/drm_pci.o
CC drivers/gpu/drm/drm_debugfs.o
CC net/netfilter/xt_ecn.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_fw.o
CC fs/io-wq.o
CC drivers/gpu/drm/drm_debugfs_crc.o
CC fs/dax.o
CC fs/xfs/xfs_pwork.o
CC fs/xfs/xfs_reflink.o
CC drivers/gpu/drm/drm_mipi_dsi.o
CC fs/locks.o
CC fs/xfs/xfs_stats.o
CC net/netfilter/xt_esp.o
CC fs/xfs/xfs_super.o
CC net/netfilter/xt_hashlimit.o
CC fs/compat.o
CC net/netfilter/xt_helper.o
CC fs/binfmt_misc.o
CC drivers/gpu/drm/drm_panel_orientation_quirks.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_log.o
CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o
CC net/netfilter/xt_hl.o
CC fs/binfmt_script.o
CC net/netfilter/xt_ipcomp.o
CC net/netfilter/xt_iprange.o
CC fs/binfmt_elf.o
CC fs/compat_binfmt_elf.o
CC net/netfilter/xt_ipvs.o
CC net/netfilter/xt_l2tp.o
CC fs/mbcache.o
CC net/netfilter/xt_length.o
CC net/netfilter/xt_limit.o
CC net/netfilter/xt_mac.o
CC drivers/gpu/drm/i915/gt/uc/intel_huc.o
CC fs/posix_acl.o
CC fs/drop_caches.o
CC fs/coredump.o
CC drivers/gpu/drm/i915/gt/uc/intel_huc_fw.o
CC fs/xfs/xfs_symlink.o
CC fs/fhandle.o
CC drivers/gpu/drm/i915/display/intel_atomic.o
CC fs/dcookies.o
CC fs/xfs/xfs_sysfs.o
CC drivers/gpu/drm/i915/display/intel_atomic_plane.o
CC fs/xfs/xfs_trans.o
CC fs/xfs/xfs_xattr.o
CC net/netfilter/xt_multiport.o
CC net/netfilter/xt_nfacct.o
CC net/netfilter/xt_osf.o
CC drivers/gpu/drm/i915/display/intel_audio.o
CC net/netfilter/xt_owner.o
CC net/netfilter/xt_cgroup.o
CC fs/xfs/kmem.o
CC drivers/gpu/drm/i915/display/intel_bios.o
AR fs/ocfs2/built-in.a
CC fs/xfs/xfs_log.o
CC fs/xfs/xfs_log_cil.o
CC drivers/gpu/drm/i915/display/intel_bw.o
CC drivers/gpu/drm/i915/display/intel_cdclk.o
CC drivers/gpu/drm/i915/display/intel_color.o
CC fs/xfs/xfs_bmap_item.o
CC drivers/gpu/drm/i915/display/intel_combo_phy.o
CC fs/xfs/xfs_buf_item.o
CC net/netfilter/xt_physdev.o
CC drivers/gpu/drm/i915/display/intel_connector.o
CC fs/xfs/xfs_extfree_item.o
CC drivers/gpu/drm/i915/display/intel_display.o
CC net/netfilter/xt_pkttype.o
CC net/netfilter/xt_policy.o
CC drivers/gpu/drm/i915/display/intel_display_power.o
CC fs/xfs/xfs_icreate_item.o
CC fs/xfs/xfs_inode_item.o
CC drivers/gpu/drm/i915/display/intel_dpio_phy.o
CC drivers/gpu/drm/i915/display/intel_dpll_mgr.o
CC fs/xfs/xfs_refcount_item.o
CC net/netfilter/xt_quota.o
CC drivers/gpu/drm/i915/display/intel_dsb.o
CC net/netfilter/xt_rateest.o
CC net/netfilter/xt_realm.o
CC drivers/gpu/drm/i915/display/intel_fbc.o
CC drivers/gpu/drm/i915/display/intel_fifo_underrun.o
CC fs/xfs/xfs_rmap_item.o
CC fs/xfs/xfs_log_recover.o
CC net/netfilter/xt_recent.o
CC net/netfilter/xt_sctp.o
CC fs/xfs/xfs_trans_ail.o
CC net/netfilter/xt_socket.o
CC drivers/gpu/drm/i915/display/intel_frontbuffer.o
CC drivers/gpu/drm/i915/display/intel_hdcp.o
CC fs/xfs/xfs_trans_buf.o
CC net/netfilter/xt_state.o
CC drivers/gpu/drm/i915/display/intel_hotplug.o
CC net/netfilter/xt_statistic.o
CC fs/xfs/xfs_dquot.o
CC net/netfilter/xt_string.o
CC net/netfilter/xt_tcpmss.o
CC net/netfilter/xt_time.o
CC fs/xfs/xfs_dquot_item.o
CC fs/xfs/xfs_trans_dquot.o
CC fs/xfs/xfs_qm_syscalls.o
CC drivers/gpu/drm/i915/display/intel_lpe_audio.o
CC net/netfilter/xt_u32.o
CC fs/xfs/xfs_qm_bhv.o
CC drivers/gpu/drm/i915/display/intel_overlay.o
CC drivers/gpu/drm/i915/display/intel_psr.o
CC fs/xfs/xfs_qm.o
CC drivers/gpu/drm/i915/display/intel_quirks.o
CC fs/xfs/xfs_quotaops.o
CC fs/xfs/xfs_rtalloc.o
CC fs/xfs/xfs_acl.o
CC fs/xfs/xfs_sysctl.o
CC fs/xfs/xfs_ioctl32.o
CC fs/xfs/xfs_pnfs.o
CC drivers/gpu/drm/i915/display/intel_sprite.o
CC drivers/gpu/drm/i915/display/intel_tc.o
CC drivers/gpu/drm/i915/display/intel_vga.o
CC drivers/gpu/drm/i915/display/intel_acpi.o
CC drivers/gpu/drm/i915/display/intel_opregion.o
CC drivers/gpu/drm/i915/display/intel_fbdev.o
CC drivers/gpu/drm/i915/display/dvo_ch7017.o
CC drivers/gpu/drm/i915/display/dvo_ch7xxx.o
CC drivers/gpu/drm/i915/display/dvo_ivch.o
CC drivers/gpu/drm/i915/display/dvo_ns2501.o
CC drivers/gpu/drm/i915/display/dvo_sil164.o
CC drivers/gpu/drm/i915/display/dvo_tfp410.o
CC drivers/gpu/drm/i915/display/icl_dsi.o
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
CC drivers/gpu/drm/i915/display/intel_dp.o
CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
CC drivers/gpu/drm/i915/display/intel_dsi.o
CC drivers/gpu/drm/i915/display/intel_dp_mst.o
CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
CC drivers/gpu/drm/i915/display/intel_gmbus.o
CC drivers/gpu/drm/i915/display/intel_dvo.o
CC drivers/gpu/drm/i915/display/intel_hdmi.o
CC drivers/gpu/drm/i915/display/intel_lspcon.o
AR net/netfilter/built-in.a
CC drivers/gpu/drm/i915/display/intel_lvds.o
AR net/built-in.a
CC drivers/gpu/drm/i915/display/intel_panel.o
CC drivers/gpu/drm/i915/display/intel_sdvo.o
CC drivers/gpu/drm/i915/display/intel_tv.o
CC drivers/gpu/drm/i915/display/intel_vdsc.o
CC drivers/gpu/drm/i915/display/vlv_dsi.o
CC drivers/gpu/drm/i915/display/vlv_dsi_pll.o
CC drivers/gpu/drm/i915/oa/i915_oa_hsw.o
CC drivers/gpu/drm/i915/oa/i915_oa_bdw.o
CC drivers/gpu/drm/i915/oa/i915_oa_chv.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt2.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt4.o
CC drivers/gpu/drm/i915/oa/i915_oa_bxt.o
CC drivers/gpu/drm/i915/oa/i915_oa_kblgt2.o
CC drivers/gpu/drm/i915/oa/i915_oa_kblgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_glk.o
CC drivers/gpu/drm/i915/oa/i915_oa_cflgt2.o
CC drivers/gpu/drm/i915/oa/i915_oa_cflgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_icl.o
CC drivers/gpu/drm/i915/oa/i915_oa_cnl.o
CC drivers/gpu/drm/i915/oa/i915_oa_tgl.o
AR fs/btrfs/built-in.a
CC drivers/gpu/drm/i915/i915_gpu_error.o
CC drivers/gpu/drm/i915/i915_perf.o
CC drivers/gpu/drm/i915/i915_vgpu.o
AR fs/xfs/built-in.a
AR fs/built-in.a
AR drivers/gpu/drm/i915/built-in.a
AR drivers/gpu/drm/built-in.a
AR drivers/gpu/built-in.a
Makefile:1681: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=148c5f29e00000
Tested on:
commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
dashboard link: https://syzkaller.appspot.com/bug?extid=cd66e43794b178bb5cd6
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
patch: https://syzkaller.appspot.com/x/patch.diff?x=1336c0a9e00000
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 7:45 general protection fault in syscall_return_slowpath syzbot
` (2 preceding siblings ...)
2020-03-08 17:20 ` Jann Horn
@ 2020-03-08 18:35 ` Jann Horn
2020-03-08 21:57 ` syzbot
2020-03-09 8:20 ` Dmitry Vyukov
2020-08-15 10:18 ` syzbot
4 siblings, 2 replies; 20+ messages in thread
From: Jann Horn @ 2020-03-08 18:35 UTC (permalink / raw)
To: syzbot
Cc: Borislav Petkov, H . Peter Anvin, kernel list, Andy Lutomirski,
Ingo Molnar, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers
[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]
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...
#syz test: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
63623fd44972d1ed2bfb6e0fb631dfcf547fd1e7
[-- Attachment #2: v2-0001-FOR-TESTING-ONLY-tell-us-which-fbcon-implementati.patch --]
[-- Type: text/x-patch, Size: 1198 bytes --]
From 8442144fe582ab38985378cf21ca88de1594b5df Mon Sep 17 00:00:00 2001
From: Jann Horn <jannh@google.com>
Date: Sun, 8 Mar 2020 18:15:11 +0100
Subject: [PATCH v2] FOR TESTING ONLY: tell us which fbcon implementation is
used
---
drivers/tty/vt/vt.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 0cfbb7182b5a..b3dd44802208 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4590,7 +4590,7 @@ static int con_font_copy(struct vc_data *vc, struct console_font_op *op)
{
int con = op->height;
int rc;
-
+ static void *LAST;
console_lock();
if (vc->vc_mode != KD_TEXT)
@@ -4601,8 +4601,14 @@ static int con_font_copy(struct vc_data *vc, struct console_font_op *op)
rc = -ENOTTY;
else if (con == vc->vc_num) /* nothing to do */
rc = 0;
- else
+ else {
+ if (LAST != vc->vc_sw) {
+ pr_warn("con_font_copy(): vc_sw=%pS, vc_sw->con_font_copy=%pS\n",
+ vc->vc_sw, vc->vc_sw->con_font_copy);
+ LAST = vc->vc_sw;
+ }
rc = vc->vc_sw->con_font_copy(vc, con);
+ }
console_unlock();
return rc;
}
base-commit: 63623fd44972d1ed2bfb6e0fb631dfcf547fd1e7
--
2.25.1.481.gfbce0eb801-goog
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 18:35 ` Jann Horn
@ 2020-03-08 21:57 ` syzbot
2020-03-09 8:20 ` Dmitry Vyukov
1 sibling, 0 replies; 20+ messages in thread
From: syzbot @ 2020-03-08 21:57 UTC (permalink / raw)
To: bp, hpa, jannh, linux-kernel, luto, mingo, syzkaller-bugs, tglx, x86
Hello,
syzbot tried to test the proposed patch but build/boot failed:
int.o
CC net/nfc/hci/llc.o
CC fs/super.o
CC fs/char_dev.o
CC fs/f2fs/gc.o
CC net/netfilter/nf_flow_table_core.o
CC net/vmw_vsock/af_vsock.o
CC net/vmw_vsock/af_vsock_tap.o
CC net/mac80211/tx.o
CC fs/stat.o
CC fs/gfs2/export.o
CC fs/gfs2/file.o
CC fs/f2fs/data.o
CC net/openvswitch/dp_notify.o
CC lib/timerqueue.o
CC net/ceph/auth_none.o
CC lib/vsprintf.o
CC net/nfc/hci/llc_nop.o
CC net/openvswitch/flow.o
CC fs/gfs2/ops_fstype.o
CC fs/btrfs/transaction.o
CC fs/btrfs/inode.o
CC fs/gfs2/inode.o
CC net/ceph/crypto.o
CC lib/win_minmax.o
CC net/nfc/hci/llc_shdlc.o
CC net/ceph/armor.o
CC net/ceph/auth_x.o
CC net/netfilter/nf_flow_table_ip.o
CC fs/f2fs/node.o
CC net/ceph/ceph_hash.o
CC net/ceph/ceph_strings.o
CC net/ceph/pagevec.o
CC drivers/gpu/drm/i915/display/intel_sprite.o
CC fs/btrfs/file.o
CC net/mac80211/key.o
CC net/openvswitch/flow_netlink.o
CC fs/ceph/caps.o
CC fs/gfs2/quota.o
CC fs/ceph/snap.o
CC net/mac80211/util.o
CC net/ceph/snapshot.o
CC net/ceph/string_table.o
CC drivers/gpu/drm/i915/display/intel_tc.o
CC drivers/gpu/drm/i915/display/intel_vga.o
CC drivers/gpu/drm/i915/display/intel_acpi.o
CC fs/xfs/libxfs/xfs_dir2_data.o
CC fs/f2fs/segment.o
CC drivers/gpu/drm/i915/display/intel_opregion.o
CC fs/gfs2/recovery.o
CC fs/gfs2/rgrp.o
CC net/vmw_vsock/vsock_addr.o
CC fs/exec.o
CC lib/xarray.o
CC net/mac80211/wme.o
CC net/netfilter/nf_flow_table_offload.o
CC net/mac80211/chan.o
CC fs/gfs2/sys.o
CC fs/gfs2/super.o
CC net/openvswitch/flow_table.o
AR fs/erofs/built-in.a
CC net/openvswitch/meter.o
AR net/nfc/hci/built-in.a
CC fs/pipe.o
CC fs/gfs2/trans.o
CC net/mac80211/trace.o
CC net/nfc/af_nfc.o
CC fs/ceph/xattr.o
CC net/openvswitch/vport.o
CC fs/namei.o
CC fs/fcntl.o
CC fs/gfs2/util.o
CC net/openvswitch/vport-internal_dev.o
CC fs/xfs/libxfs/xfs_dir2_leaf.o
CC drivers/gpu/drm/i915/display/intel_fbdev.o
CC fs/xfs/libxfs/xfs_dir2_node.o
CC drivers/gpu/drm/i915/display/dvo_ch7xxx.o
CC drivers/gpu/drm/i915/display/dvo_ch7017.o
CC net/netfilter/nf_flow_table_inet.o
CC drivers/gpu/drm/i915/display/dvo_ivch.o
CC net/openvswitch/vport-netdev.o
AR net/batman-adv/built-in.a
CC net/vmw_vsock/diag.o
CC net/vmw_vsock/virtio_transport.o
CC fs/gfs2/lock_dlm.o
CC net/mpls/mpls_gso.o
CC fs/ceph/quota.o
AR net/ceph/built-in.a
CC fs/xfs/libxfs/xfs_dir2_sf.o
CC net/nfc/rawsock.o
CC net/openvswitch/conntrack.o
CC fs/xfs/libxfs/xfs_dquot_buf.o
CC net/nfc/llcp_core.o
CC net/netfilter/x_tables.o
CC net/netfilter/xt_tcpudp.o
CC net/nsh/nsh.o
CC net/mac80211/mlme.o
CC fs/f2fs/recovery.o
CC net/hsr/hsr_main.o
CC net/hsr/hsr_device.o
CC net/hsr/hsr_framereg.o
CC net/hsr/hsr_netlink.o
CC fs/f2fs/shrinker.o
CC net/mac80211/tdls.o
CC net/openvswitch/vport-geneve.o
CC net/openvswitch/vport-vxlan.o
CC drivers/gpu/drm/i915/display/dvo_ns2501.o
CC net/hsr/hsr_slave.o
CC net/netfilter/xt_mark.o
GEN lib/crc32table.h
CC net/openvswitch/vport-gre.o
CC net/mpls/af_mpls.o
CC fs/ceph/io.o
GEN lib/crc64table.h
CC fs/f2fs/extent_cache.o
CC fs/f2fs/sysfs.o
CC net/netfilter/xt_connmark.o
CC fs/ceph/mds_client.o
CC fs/ceph/strings.o
CC fs/ceph/mdsmap.o
CC fs/xfs/libxfs/xfs_ialloc.o
CC net/vmw_vsock/virtio_transport_common.o
CC fs/xfs/libxfs/xfs_ialloc_btree.o
CC fs/xfs/libxfs/xfs_iext_tree.o
CC fs/btrfs/tree-defrag.o
CC net/switchdev/switchdev.o
CC net/nfc/llcp_commands.o
CC net/nfc/llcp_sock.o
CC net/nfc/digital_core.o
CC net/nfc/digital_technology.o
CC net/nfc/digital_dep.o
CC fs/xfs/libxfs/xfs_inode_fork.o
CC fs/xfs/libxfs/xfs_inode_buf.o
AR fs/gfs2/built-in.a
CC fs/f2fs/debug.o
CC fs/btrfs/extent_map.o
CC net/hsr/hsr_forward.o
CC net/netfilter/xt_set.o
CC net/netfilter/xt_nat.o
CC net/mac80211/ocb.o
CC net/mac80211/airtime.o
CC fs/ceph/ceph_frag.o
CC lib/oid_registry.o
AR lib/lib.a
AR net/nsh/built-in.a
CC fs/xfs/libxfs/xfs_log_rlimit.o
CC drivers/gpu/drm/i915/display/dvo_sil164.o
CC fs/ceph/debugfs.o
CC net/hsr/hsr_debugfs.o
CC net/mac80211/led.o
CC net/mac80211/debugfs.o
CC fs/ceph/cache.o
CC fs/ceph/util.o
CC fs/f2fs/xattr.o
CC fs/btrfs/sysfs.o
CC fs/ceph/acl.o
CC fs/btrfs/struct-funcs.o
CC net/netfilter/xt_AUDIT.o
CC fs/f2fs/acl.o
CC net/netfilter/xt_CHECKSUM.o
CC fs/ioctl.o
CC net/netfilter/xt_CLASSIFY.o
CC net/netfilter/xt_CONNSECMARK.o
CC net/mac80211/debugfs_sta.o
CC fs/readdir.o
CC lib/crc32.o
AR net/openvswitch/built-in.a
CC fs/btrfs/xattr.o
CC fs/xfs/libxfs/xfs_ag_resv.o
CC fs/btrfs/ordered-data.o
CC net/mac80211/debugfs_netdev.o
CC net/mac80211/debugfs_key.o
CC fs/xfs/libxfs/xfs_rmap.o
CC fs/xfs/libxfs/xfs_rmap_btree.o
AR fs/ocfs2/built-in.a
CC net/mac80211/mesh.o
CC net/vmw_vsock/vsock_loopback.o
CC fs/xfs/libxfs/xfs_refcount.o
AR net/hsr/built-in.a
CC net/mpls/mpls_iptunnel.o
CC fs/f2fs/verity.o
CC net/mac80211/mesh_pathtbl.o
CC fs/f2fs/compress.o
AR net/nfc/built-in.a
CC net/netfilter/xt_CT.o
CC net/l3mdev/l3mdev.o
EXPORTS lib/lib-ksyms.o
CC lib/crc64.o
CC net/mac80211/mesh_plink.o
CC net/mac80211/mesh_hwmp.o
CC drivers/gpu/drm/i915/display/dvo_tfp410.o
CC fs/xfs/libxfs/xfs_refcount_btree.o
CC net/netfilter/xt_DSCP.o
CC net/mac80211/mesh_sync.o
CC fs/select.o
CC net/mac80211/mesh_ps.o
CC net/netfilter/xt_HL.o
CC fs/xfs/libxfs/xfs_sb.o
AR net/switchdev/built-in.a
CC fs/xfs/libxfs/xfs_symlink_remote.o
CC fs/btrfs/extent_io.o
CC fs/btrfs/volumes.o
CC fs/btrfs/async-thread.o
CC fs/btrfs/ioctl.o
CC net/netfilter/xt_HMARK.o
CC net/mac80211/pm.o
CC fs/xfs/libxfs/xfs_trans_inode.o
CC fs/xfs/libxfs/xfs_trans_resv.o
CC fs/xfs/libxfs/xfs_types.o
CC fs/xfs/libxfs/xfs_rtbitmap.o
AR lib/built-in.a
CC net/netfilter/xt_LED.o
CC net/netfilter/xt_LOG.o
CC fs/btrfs/locking.o
CC fs/xfs/xfs_aops.o
CC fs/inode.o
CC fs/dcache.o
CC fs/attr.o
AR net/vmw_vsock/built-in.a
CC fs/bad_inode.o
CC net/mac80211/rc80211_minstrel.o
CC fs/file.o
CC fs/xfs/xfs_attr_inactive.o
CC fs/filesystems.o
CC fs/namespace.o
CC fs/seq_file.o
CC drivers/gpu/drm/i915/display/icl_dsi.o
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
AR net/mpls/built-in.a
CC net/ncsi/ncsi-cmd.o
CC net/xdp/xsk.o
CC net/netfilter/xt_NETMAP.o
AR net/l3mdev/built-in.a
CC net/mptcp/protocol.o
CC fs/xfs/xfs_attr_list.o
AR fs/ceph/built-in.a
CC net/netfilter/xt_NFLOG.o
CC net/ncsi/ncsi-rsp.o
CC net/mptcp/subflow.o
CC net/mptcp/options.o
CC net/netfilter/xt_NFQUEUE.o
CC drivers/gpu/drm/i915/display/intel_dp.o
CC net/mac80211/rc80211_minstrel_ht.o
CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
CC net/mac80211/rc80211_minstrel_debugfs.o
CC fs/xattr.o
CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
CC net/netfilter/xt_RATEEST.o
CC fs/xfs/xfs_bmap_util.o
CC fs/btrfs/orphan.o
CC fs/xfs/xfs_bio_io.o
CC fs/btrfs/export.o
CC net/mac80211/rc80211_minstrel_ht_debugfs.o
CC fs/xfs/xfs_buf.o
CC fs/xfs/xfs_dir2_readdir.o
CC fs/xfs/xfs_discard.o
CC drivers/gpu/drm/i915/display/intel_dp_mst.o
CC fs/btrfs/tree-log.o
CC fs/btrfs/free-space-cache.o
CC fs/xfs/xfs_error.o
CC fs/btrfs/zlib.o
CC fs/xfs/xfs_export.o
AR fs/f2fs/built-in.a
CC fs/btrfs/lzo.o
CC net/socket.o
CC net/compat.o
CC fs/libfs.o
CC fs/xfs/xfs_extent_busy.o
CC fs/xfs/xfs_file.o
CC fs/fs-writeback.o
CC fs/pnode.o
CC fs/xfs/xfs_filestream.o
CC net/netfilter/xt_REDIRECT.o
CC fs/xfs/xfs_fsmap.o
CC net/ncsi/ncsi-aen.o
CC net/xdp/xdp_umem.o
CC net/xdp/xsk_queue.o
CC net/xdp/xsk_diag.o
CC net/netfilter/xt_MASQUERADE.o
CC drivers/gpu/drm/i915/display/intel_dsi.o
CC net/sysctl_net.o
CC net/netfilter/xt_SECMARK.o
CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
CC fs/xfs/xfs_fsops.o
CC fs/xfs/xfs_globals.o
CC fs/xfs/xfs_health.o
CC fs/xfs/xfs_icache.o
CC fs/btrfs/zstd.o
CC net/mptcp/token.o
CC net/mptcp/crypto.o
CC net/ncsi/ncsi-manage.o
CC fs/xfs/xfs_ioctl.o
CC fs/xfs/xfs_iomap.o
CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
CC fs/btrfs/compression.o
CC net/netfilter/xt_TPROXY.o
CC net/netfilter/xt_TCPMSS.o
CC net/ncsi/ncsi-netlink.o
CC fs/btrfs/delayed-ref.o
CC drivers/gpu/drm/i915/display/intel_dvo.o
CC fs/btrfs/relocation.o
CC fs/btrfs/delayed-inode.o
CC drivers/gpu/drm/i915/display/intel_gmbus.o
CC net/mptcp/ctrl.o
CC drivers/gpu/drm/i915/display/intel_hdmi.o
CC fs/xfs/xfs_iops.o
CC fs/splice.o
CC drivers/gpu/drm/i915/display/intel_lspcon.o
CC fs/xfs/xfs_inode.o
CC fs/xfs/xfs_itable.o
CC fs/btrfs/scrub.o
CC fs/btrfs/reada.o
CC fs/btrfs/backref.o
CC fs/sync.o
CC net/netfilter/xt_TCPOPTSTRIP.o
CC fs/utimes.o
CC drivers/gpu/drm/i915/display/intel_lvds.o
CC fs/btrfs/ulist.o
CC fs/xfs/xfs_iwalk.o
CC fs/xfs/xfs_message.o
CC fs/xfs/xfs_mount.o
CC fs/btrfs/qgroup.o
CC fs/btrfs/send.o
CC fs/d_path.o
CC fs/xfs/xfs_mru_cache.o
CC net/netfilter/xt_IDLETIMER.o
CC net/netfilter/xt_TRACE.o
CC net/netfilter/xt_TEE.o
CC net/netfilter/xt_addrtype.o
CC net/netfilter/xt_bpf.o
CC fs/stack.o
CC fs/xfs/xfs_pwork.o
CC fs/fs_struct.o
CC fs/btrfs/dev-replace.o
AR net/xdp/built-in.a
CC fs/btrfs/raid56.o
CC fs/btrfs/uuid-tree.o
CC fs/statfs.o
CC net/netfilter/xt_cluster.o
CC fs/xfs/xfs_reflink.o
AR net/mptcp/built-in.a
CC fs/xfs/xfs_stats.o
AR net/mac80211/built-in.a
CC fs/xfs/xfs_super.o
CC fs/fs_pin.o
CC net/netfilter/xt_comment.o
CC net/netfilter/xt_connbytes.o
CC net/netfilter/xt_connlabel.o
CC net/netfilter/xt_connlimit.o
CC fs/xfs/xfs_symlink.o
CC net/netfilter/xt_conntrack.o
CC fs/xfs/xfs_sysfs.o
CC fs/xfs/xfs_trans.o
CC fs/nsfs.o
CC fs/btrfs/props.o
CC fs/btrfs/free-space-tree.o
CC net/netfilter/xt_cpu.o
CC net/netfilter/xt_dccp.o
CC fs/btrfs/tree-checker.o
CC fs/fs_types.o
CC net/netfilter/xt_devgroup.o
CC fs/fs_context.o
CC fs/xfs/xfs_xattr.o
CC fs/btrfs/space-info.o
CC fs/fsopen.o
CC fs/fs_parser.o
CC drivers/gpu/drm/i915/display/intel_panel.o
CC drivers/gpu/drm/i915/display/intel_sdvo.o
CC fs/xfs/kmem.o
CC fs/btrfs/block-rsv.o
CC fs/xfs/xfs_log.o
CC fs/xfs/xfs_log_cil.o
CC fs/xfs/xfs_bmap_item.o
CC fs/btrfs/delalloc-space.o
CC fs/btrfs/block-group.o
CC drivers/gpu/drm/i915/display/intel_tv.o
AR net/ncsi/built-in.a
CC net/netfilter/xt_dscp.o
CC fs/buffer.o
CC fs/xfs/xfs_buf_item.o
CC net/netfilter/xt_ecn.o
CC fs/btrfs/discard.o
CC fs/block_dev.o
CC drivers/gpu/drm/i915/display/intel_vdsc.o
CC drivers/gpu/drm/i915/display/vlv_dsi.o
CC fs/xfs/xfs_extfree_item.o
CC fs/xfs/xfs_icreate_item.o
CC fs/btrfs/acl.o
CC net/netfilter/xt_esp.o
CC net/netfilter/xt_hashlimit.o
CC fs/xfs/xfs_inode_item.o
CC fs/xfs/xfs_refcount_item.o
CC fs/xfs/xfs_rmap_item.o
CC fs/xfs/xfs_log_recover.o
CC drivers/gpu/drm/i915/display/vlv_dsi_pll.o
CC drivers/gpu/drm/i915/oa/i915_oa_hsw.o
CC fs/xfs/xfs_trans_ail.o
CC fs/xfs/xfs_trans_buf.o
CC fs/direct-io.o
CC fs/mpage.o
CC fs/proc_namespace.o
CC fs/eventpoll.o
CC fs/anon_inodes.o
CC fs/xfs/xfs_dquot.o
CC fs/signalfd.o
CC fs/timerfd.o
CC net/netfilter/xt_helper.o
CC fs/eventfd.o
CC net/netfilter/xt_hl.o
CC drivers/gpu/drm/i915/oa/i915_oa_bdw.o
CC drivers/gpu/drm/i915/oa/i915_oa_chv.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt2.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_sklgt4.o
CC net/netfilter/xt_ipcomp.o
CC fs/xfs/xfs_dquot_item.o
CC drivers/gpu/drm/i915/oa/i915_oa_bxt.o
CC fs/xfs/xfs_trans_dquot.o
CC drivers/gpu/drm/i915/oa/i915_oa_kblgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_kblgt2.o
CC net/netfilter/xt_iprange.o
CC drivers/gpu/drm/i915/oa/i915_oa_glk.o
CC fs/xfs/xfs_qm_syscalls.o
CC fs/userfaultfd.o
CC fs/aio.o
CC fs/io_uring.o
CC net/netfilter/xt_ipvs.o
CC net/netfilter/xt_l2tp.o
CC net/netfilter/xt_length.o
CC fs/xfs/xfs_qm_bhv.o
CC net/netfilter/xt_limit.o
CC fs/xfs/xfs_qm.o
CC drivers/gpu/drm/i915/oa/i915_oa_cflgt2.o
CC fs/io-wq.o
CC net/netfilter/xt_mac.o
CC drivers/gpu/drm/i915/oa/i915_oa_cflgt3.o
CC drivers/gpu/drm/i915/oa/i915_oa_cnl.o
CC net/netfilter/xt_multiport.o
CC fs/xfs/xfs_quotaops.o
CC net/netfilter/xt_osf.o
CC net/netfilter/xt_nfacct.o
CC fs/xfs/xfs_rtalloc.o
CC fs/xfs/xfs_acl.o
CC drivers/gpu/drm/i915/oa/i915_oa_icl.o
CC net/netfilter/xt_owner.o
CC fs/dax.o
CC fs/locks.o
CC fs/compat.o
CC fs/binfmt_misc.o
CC drivers/gpu/drm/i915/oa/i915_oa_tgl.o
CC net/netfilter/xt_physdev.o
CC net/netfilter/xt_cgroup.o
CC net/netfilter/xt_pkttype.o
CC net/netfilter/xt_quota.o
CC net/netfilter/xt_policy.o
CC fs/binfmt_script.o
CC net/netfilter/xt_rateest.o
CC fs/xfs/xfs_sysctl.o
CC net/netfilter/xt_realm.o
CC drivers/gpu/drm/i915/i915_perf.o
CC drivers/gpu/drm/i915/i915_gpu_error.o
CC fs/xfs/xfs_ioctl32.o
CC fs/binfmt_elf.o
CC net/netfilter/xt_recent.o
CC net/netfilter/xt_sctp.o
CC net/netfilter/xt_socket.o
CC net/netfilter/xt_state.o
CC fs/xfs/xfs_pnfs.o
CC drivers/gpu/drm/i915/i915_vgpu.o
CC fs/compat_binfmt_elf.o
CC fs/posix_acl.o
CC fs/mbcache.o
CC fs/coredump.o
CC net/netfilter/xt_statistic.o
CC fs/drop_caches.o
CC net/netfilter/xt_string.o
CC fs/fhandle.o
CC net/netfilter/xt_tcpmss.o
CC fs/dcookies.o
CC net/netfilter/xt_time.o
CC net/netfilter/xt_u32.o
AR net/netfilter/built-in.a
AR net/built-in.a
AR drivers/gpu/drm/i915/built-in.a
AR drivers/gpu/drm/built-in.a
AR drivers/gpu/built-in.a
Makefile:1681: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
AR fs/btrfs/built-in.a
AR fs/xfs/built-in.a
AR fs/built-in.a
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=1771d70de00000
Tested on:
commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
dashboard link: https://syzkaller.appspot.com/bug?extid=cd66e43794b178bb5cd6
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
patch: https://syzkaller.appspot.com/x/patch.diff?x=1161a0b1e00000
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 18:35 ` Jann Horn
2020-03-08 21:57 ` syzbot
@ 2020-03-09 8:20 ` Dmitry Vyukov
2020-03-10 6:15 ` Nathan Chancellor
1 sibling, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2020-03-09 8:20 UTC (permalink / raw)
To: Jann Horn, syzkaller
Cc: syzbot, Borislav Petkov, H . Peter Anvin, kernel list,
Andy Lutomirski, Ingo Molnar, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers
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...
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?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-09 8:20 ` Dmitry Vyukov
@ 2020-03-10 6:15 ` Nathan Chancellor
2020-03-10 8:10 ` Dmitry Vyukov
0 siblings, 1 reply; 20+ messages in thread
From: Nathan Chancellor @ 2020-03-10 6:15 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Jann Horn, syzkaller, syzbot, Borislav Petkov, H . Peter Anvin,
kernel list, Andy Lutomirski, Ingo Molnar, syzkaller-bugs,
Thomas Gleixner, the arch/x86 maintainers
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-10 6:15 ` Nathan Chancellor
@ 2020-03-10 8:10 ` Dmitry Vyukov
2020-06-14 8:03 ` Dmitry Vyukov
0 siblings, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2020-03-10 8:10 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jann Horn, syzkaller, syzbot, Borislav Petkov, H . Peter Anvin,
kernel list, Andy Lutomirski, Ingo Molnar, syzkaller-bugs,
Thomas Gleixner, the arch/x86 maintainers
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-10 8:10 ` Dmitry Vyukov
@ 2020-06-14 8:03 ` Dmitry Vyukov
2020-06-15 7:57 ` Jann Horn
0 siblings, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2020-06-14 8:03 UTC (permalink / raw)
To: Jann Horn
Cc: syzkaller, syzbot, Borislav Petkov, H . Peter Anvin, kernel list,
Andy Lutomirski, Ingo Molnar, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers, Nathan Chancellor, Dan Carpenter
On Tue, Mar 10, 2020 at 9:10 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> 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.
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...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-06-14 8:03 ` Dmitry Vyukov
@ 2020-06-15 7:57 ` Jann Horn
0 siblings, 0 replies; 20+ messages in thread
From: Jann Horn @ 2020-06-15 7:57 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzkaller, syzbot, Borislav Petkov, H . Peter Anvin, kernel list,
Andy Lutomirski, Ingo Molnar, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers, Nathan Chancellor, Dan Carpenter
On Sun, Jun 14, 2020 at 10:03 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 10, 2020 at 9:10 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > 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:
> > > > > 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.
Ah, I guess you have a point there.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: general protection fault in syscall_return_slowpath
2020-03-08 7:45 general protection fault in syscall_return_slowpath syzbot
` (3 preceding siblings ...)
2020-03-08 18:35 ` Jann Horn
@ 2020-08-15 10:18 ` syzbot
4 siblings, 0 replies; 20+ messages in thread
From: syzbot @ 2020-08-15 10:18 UTC (permalink / raw)
To: bp, dan.carpenter, daniel.vetter, dvyukov, gregkh, hpa, jannh,
linux-kernel, luto, mingo, natechancellor, penguin-kernel,
penguin-kernel, syzkaller-bugs, syzkaller, tglx, x86
syzbot suspects this issue was fixed by commit:
commit 033724d6864245a11f8e04c066002e6ad22b3fd0
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Wed Jul 15 01:51:02 2020 +0000
fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13f979f6900000
start commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f
dashboard link: https://syzkaller.appspot.com/bug?extid=cd66e43794b178bb5cd6
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a42329e00000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 20+ messages in thread