Help needed for reproducing a crash

318 views
Skip to first unread message

Hassan Shahbazi

unread,
Mar 22, 2021, 7:05:59 AM3/22/21
to syzkaller
Hello all,

I have been newly interested to take part in Kernel development, and I decided to move forward with reproducing a bug reported by syz-bot and fixing it. I decided to reproduce this NULL pointer deference crash report: https://syzkaller.appspot.com/bug?id=defb47bf56e1c14d5687280c7bb91ce7b608b94b

I used available documents and set up qemu on an Ubuntu Linux for Kernel testing purposes. I also followed documents on reproducing bugs described in: https://github.com/google/syzkaller/blob/master/docs/reproducing_crashes.md

However, when I run the command* to reproduce the crash, the result always contains either program crash: KASAN: stack-out-of-bounds or program did not crash. I have never succeeded in getting the same sort of crash, though I am sure the bug has not been resolved.

I would appreciate any guide to overcome this issue. Hope I can learn from you and fix more crashes.

* syz-repro -config syzkaller.cfg linux-repro/repro.syz


Dmitry Vyukov

unread,
Mar 23, 2021, 3:52:47 AM3/23/21
to Hassan Shahbazi, syzkaller
Hi Hassan,

Since this bug has a C reproducer:
https://syzkaller.appspot.com/text?tag=ReproC&x=16123ff2d00000
It's simpler to just run this C program instead of using
reproducing_crashes.md instructions.

Re reproducing, I am assuming you used the provided kernel commit
5695e516 and the provided config, right? Matching these is the
simplest step.

Some kernel bugs may be dependent on hardware. And since this repro
involves /dev/fb0 device, it may be the case here.
The x86 crashes happened on GCE VMs. There is also 1 crash that
happened in qemu, but it's on arm32 arch. You can find the qemu
command line for arm32 in the "VM info" column.

If you want to understand if it's really due to hardware differences
or due to something else, I would suggest to add pr_err() printf's
along this crashing call stack:

hide_cursor+0x7e/0x310 drivers/tty/vt/vt.c:907
redraw_screen+0x190/0x11a0 drivers/tty/vt/vt.c:1012
vc_do_resize+0x1178/0x1780 drivers/tty/vt/vt.c:1325
fbcon_set_disp+0x9f2/0xf90 drivers/video/fbdev/core/fbcon.c:1402
con2fb_init_display drivers/video/fbdev/core/fbcon.c:808 [inline]
set_con2fb_map+0x7f6/0xe90 drivers/video/fbdev/core/fbcon.c:879
fbcon_set_con2fb_map_ioctl+0x19e/0x280 drivers/video/fbdev/core/fbcon.c:3010
do_fb_ioctl+0x307/0x6e0 drivers/video/fbdev/core/fbmem.c:1156
vfs_ioctl fs/ioctl.c:48 [inline]

and trace where your execution diverges from this stack, and then you
can hopefully figure out why that happens.

Or, if you are just starting, you may also pick another bug report
with a reproducer. Or continue trying other ones until you will find
one that reproduces well. I am sure there should be such reproducers.

Hassan Shahbazi

unread,
Mar 25, 2021, 8:21:20 AM3/25/21
to syzkaller
Hi Dmitry,

Thanks for your reply. I could successfully reproduce the crash
on qemu by using the same config file and the commit. Now I
can see if my patch will fix the bug or not.
Reply all
Reply to author
Forward
0 new messages