On Tue, 18 Jul 2023 at 21:39, Salvatore Bonaccorso <[email protected]> wrote: > > Hi, > > On Sun, Jul 16, 2023 at 07:47:11PM +0200, Ben Hutchings wrote: > > On Wed, 2023-06-28 at 10:26 +0200, Dmitry Vyukov wrote: > > > On Thu, 22 Jun 2023 at 16:46, Dmitry Vyukov <[email protected]> wrote: > > > > > > > > Hello, > > > > > > > > Our team works on syzkaller/syzbot kernel fuzzer: > > > > https://github.com/google/syzkaller > > > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md > > > > > > > > Currently we test the upstream kernel and recent LTS releases: > > > > https://syzkaller.appspot.com/upstream > > > > https://syzkaller.appspot.com/linux-6.1 > > > > https://syzkaller.appspot.com/linux-5.15 > > > > and report bugs to upstream developers: > > > > https://groups.google.com/g/syzkaller-bugs > > > > > > > > Due to Debian's relevance as one of the most widely used Linux > > > > distributions, we plan to test the Debian kernel as well. > > > > > > > > We were thinking about testing the "testing" release only initially. > > > > Or do you have other suggestions here? > > > > If you want to find issues affecting the next release, then that's the > > right choice. But if you want to find issues that still need fixes > > uploaded, then "unstable" is the right choice. Any fixes in testing > > need to go via unstable. > > > > > > Do you want bugs to be reported privately first (to some closed > > > > mailing list) with some embargo? Or do we make them public (visible on > > > > syzbot dashboard) right away as we do for upstream/LTS? > > > > > > +Ben, you were pointed out as the person to provide "the official" > > > response :) > > > > I'm just one person on the kernel team, and not the most active at the > > moment. Salvatore Bonaccorso is doing most of the security updates. > > > > > To clarify: we are not asking nor imply that anybody will actually act > > > in any way on the reported bugs. I mean anybody is welcome to, but > > > don't have to. > > > We can also just create a public web dashboard (+new opt-in mailing > > > list), if that's what we agree on here. > > > > > > And if there is an active interest in acting on the reports, we can > > > also test the unstable release (that's the better place to fix, > > > right). > > > > If syzbot is able to distinguish bugs that are reproducible on Debian > > patched kernels but not in the corresponding stable releases, I think > > that would be very useful to us. My guess is that this would be a > > manageable rate of bugs and we could receive those privately. What do > > you think, Salvatore? > > > > If this isn't possible, then it's unlikely we will have the time to > > look at the issues. You can create a public web dashboard but I don't > > know if that's going to help anyone. > > Yes, I do agree with the above. If syzbot can do that separation then > it would be useful, and think we can agree to get those reports > privately to either a deidcated set up distribution list or directly > to the Debian maintainers. In first stance I guess that would be Ben > and me, and possibly the others listed as Uploaders for the src:linux > package. > > OTOH, I fully agree, if syzbot canot distinguish issues reproducible > only with Debian patches applied I think we won't really have the free > time to investigate those reports. As we are doing this in our free > time. > > Thank you for approaching us on this!
Hi Ben, Salvatore, Yes, syzbot can detect "downstream" bugs with reasonable precision, e.g. for Android 5.15 tree: https://syzkaller.appspot.com/android-5-15?label=origin%3Adownstream and here you can see "Bug presence" analysis by testing on corresponding LTS and upstream trees: https://syzkaller.appspot.com/bug?extid=ea487d1ec1a25689e4d2 However, I am not sure if we can readily set up reporting of only such bugs privately.
