On Mon, 2025-07-07 at 23:57 +0200, Paul Chaignon wrote: > On Fri, Jul 04, 2025 at 10:26:14AM -0700, Eduard Zingerman wrote: > > On Fri, 2025-07-04 at 19:14 +0200, Paul Chaignon wrote: > > > On Thu, Jul 03, 2025 at 11:54:27AM -0700, Eduard Zingerman wrote: > > > > On Thu, 2025-07-03 at 19:02 +0200, Paul Chaignon wrote: > > > > > The number of times syzkaller is currently hitting this (180 in 1.5 > > > > > days) suggests there are many different ways to reproduce. > > > > > > > > It is a bit inconvenient to read syzbot BPF reports at the moment, > > > > because it us hard to figure out how the program looks like. > > > > Do you happen to know how complicated would it be to modify syzbot > > > > output to: > > > > - produce a comment with BPF program > > > > - generating reproducer with a flag, allowing to print level 2 > > > > verifier log > > > > ? > > > > > > I have the same thought sometimes. Right now, I add verifier logs to a > > > syz or C reproducer to see the program. Producing the BPF program in a > > > comment would likely be tricky as we'd need to maintain a disassembler > > > in syzkaller. > > > > So, it operates on raw bytes, not on logical instructions? > > Both I would say. The syzkaller descriptions for BPF are structured > around instructions [1], though they may not always match 1:1 with > upstream instructions. Syzkaller then mutates raw bytes, taking some > information from the descriptions into account (ex. known flag values). > > 1 - https://github.com/google/syzkaller/blob/master/sys/linux/bpf_prog.txt I actually took a brief look at syzkaller over the weekend but got lost tbh. BPF disassembler is small (~400Loc in kernel/bpf/disasm.c). I can teach myself some golang and make a copy of it in syzkaller, but having some guidance on where to put/call this code would be of much help. (I think that having program code in the report would be of great help in triaging).
