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.