How to make syzbot reports easier to debug?
summary
Syzbot produces hundreds of automated kernel bug reports a year and the hard facts that speed triage are: kdump memory dumps (useful for postmortem but large, keep one or two per bug/month), last-branch tracing or ftrace/utrace to attach execution context when no reproducer exists, and sharing a bootable disk image plus a public docker build container so rebuilts are hermetic. Reproducibility is critical; on 5.15 about 65% of reports look valid versus ~85% on newer kernels, and running unprivileged vs privileged fuzzers helps flag likely security issues.
AI-written summary · about
chapters (14)
- 0:00Introduction and goals
- 3:15Improving report debuggability
- 8:00Kernel memory dumps for crashes
- 10:05Prioritizing bug reports
- 14:47Kernel state dumps at panic
- 17:23Physical vs virtual machine testing
- 19:15Reproducibility and tooling
- 24:13Reproducibility challenges
- 26:10Bisecting bug origins
- 31:16Stable kernel regressions
- 37:04Backporting fixes to stable
- 41:29Automating backport detection
- 45:21False positives and risk assessment
- 49:02Zero-day testing integration
related talks
44mSyzbot BoF: Open Discussion
06mQ&A
21msyzbot ci: continuous patch series fuzzing
09mLinux Kernel Bug Fixing Project
36mRISC-V Bug Hunting
19mSYZOS: Practical KVM fuzzing
39mDay-to-day Testing of Linux 'Next' Kernel Branch - My Story
37mBreaking and Fixing the Kernel: Crashes, Debugging & Performance Tun...