Re: Reminder: 99 open syzbot bugs in net subsystem
On 7/30/19 8:57 PM, Eric Biggers wrote: > syzbot finds a lot of security bugs, and security bugs are important. And the > bugs are still there regardless of whether they're reported by human or bot. > > Also, there *are* bugs being fixed because of these reminders; some subsystem > maintainers have even fixed all the bugs in their subsystem. But I can > understand that for subsystems with a lot of open bug reports it's > overwhelming. > > What I'll try doing next time (if there *is* a next time; it isn't actually my > job to do any of this, I just care about the security and reliability of > Linux...) is for subsystems with lots of open bug reports, only listing the > ones > actually seen in the last week or so, and perhaps also spending some more time > manually checking those bugs. That should cut down the noise a lot. I don't think anyone questions the overall value of syzbot. It's the maintenance of bug reports that needs refining. As an example, this one: https://syzkaller.appspot.com/bug?id=079bd8408abd95b492f127edf0df44ddc09d9405 was in reality a very short-lived bug in net-next but because bpf-next managed to merge net-next in the small time window, the bug life seems more extended that it apparently was (fuzzy words since we do not know which commit fixed it). Also, there is inconsistency with the report. It shows a bisected commit of: commit f40b6ae2b612446dc970d7b51eeec47bd1619f82 Author: David Ahern Date: Thu May 23 03:27:55 2019 + ipv6: Move pcpu cached routes to fib6_nh yet the report shows an entry in net tree on April 27. Even the net instance on June 14 is questionable given that the above commit is only in net-next on June 14. Taking all of those references out and there are 2 'real', unique reports - the linux-next on May 31 and the net-next on June 5. Given that nothing has appeared in the last 8 weeks it seems clear to me that this bug has been fixed we just don't know by which commit. If there is a way to reduce to some of that information or even to have a button on that console that says 'apparently fixed' and close it would be a help.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Thu, Jul 25, 2019 at 07:04:47AM +0200, Eric Dumazet wrote: > > > On 7/24/19 11:09 PM, Eric Biggers wrote: > > On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote: > >> From: Eric Biggers > >> Date: Wed, 24 Jul 2019 11:37:12 -0700 > >> > >>> We can argue about what words to use to describe this situation, but > >>> it doesn't change the situation itself. > >> > >> And we should argue about those words because it matters to humans and > >> effects how they feel, and humans ultimately fix these bugs. > >> > >> So please stop with the hyperbole. > >> > >> Thank you. > > > > Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the > > last 7 days (90.1% with reproducers). Of those, 59 were reported over 3 > > months > > ago (89.8% with reproducers). Of those, 12 were reported over a year ago > > (83.3% > > with reproducers). > > > > No opinion on whether those are small/medium/large numbers, in case it would > > hurt someone's feelings. > > > > These numbers do *not* include bugs that are still valid but weren't seen on > > mainline in last 7 days, e.g.: > > > > - Bugs that are seen only rarely, so by chance weren't seen in last 7 days. > > - Bugs only in linux-next and/or subsystem branches. > > - Bugs that were seen in mainline more than 7 days ago, and then only on > > linux-next or subsystem branch in last 7 days. > > - Bugs that stopped being seen due to a change in syzkaller. > > - Bugs that stopped being seen due to a change in kernel config. > > - Bugs that stopped being seen due to other environment changes such as > > kernel > > command line parameters. > > - Bugs that stopped being seen due to a kernel change that hid the bug but > > didn't actually fix it, i.e. still reachable in other ways. > > > > We do not doubt syzkaller is an incredible tool. > > But netdev@ and lkml@ are mailing lists for humans to interact, > exchange ideas, send patches and review them. > > To me, an issue that was reported to netdev by a real user is _way_ more > important > than potential issues that a bot might have found doing crazy things. > > We need to keep optimal S/N on mailing lists, so any bots trying to interact > with these lists must be very cautious and damn smart. > > When I have time to spare and can work on syzbot reports, I am going to a web > page where I can see them and select the ones it makes sense to fix. > I hate having to set up email filters. > syzbot finds a lot of security bugs, and security bugs are important. And the bugs are still there regardless of whether they're reported by human or bot. Also, there *are* bugs being fixed because of these reminders; some subsystem maintainers have even fixed all the bugs in their subsystem. But I can understand that for subsystems with a lot of open bug reports it's overwhelming. What I'll try doing next time (if there *is* a next time; it isn't actually my job to do any of this, I just care about the security and reliability of Linux...) is for subsystems with lots of open bug reports, only listing the ones actually seen in the last week or so, and perhaps also spending some more time manually checking those bugs. That should cut down the noise a lot. - Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
On 7/24/19 11:09 PM, Eric Biggers wrote: > On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote: >> From: Eric Biggers >> Date: Wed, 24 Jul 2019 11:37:12 -0700 >> >>> We can argue about what words to use to describe this situation, but >>> it doesn't change the situation itself. >> >> And we should argue about those words because it matters to humans and >> effects how they feel, and humans ultimately fix these bugs. >> >> So please stop with the hyperbole. >> >> Thank you. > > Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the > last 7 days (90.1% with reproducers). Of those, 59 were reported over 3 > months > ago (89.8% with reproducers). Of those, 12 were reported over a year ago > (83.3% > with reproducers). > > No opinion on whether those are small/medium/large numbers, in case it would > hurt someone's feelings. > > These numbers do *not* include bugs that are still valid but weren't seen on > mainline in last 7 days, e.g.: > > - Bugs that are seen only rarely, so by chance weren't seen in last 7 days. > - Bugs only in linux-next and/or subsystem branches. > - Bugs that were seen in mainline more than 7 days ago, and then only on > linux-next or subsystem branch in last 7 days. > - Bugs that stopped being seen due to a change in syzkaller. > - Bugs that stopped being seen due to a change in kernel config. > - Bugs that stopped being seen due to other environment changes such as kernel > command line parameters. > - Bugs that stopped being seen due to a kernel change that hid the bug but > didn't actually fix it, i.e. still reachable in other ways. > We do not doubt syzkaller is an incredible tool. But netdev@ and lkml@ are mailing lists for humans to interact, exchange ideas, send patches and review them. To me, an issue that was reported to netdev by a real user is _way_ more important than potential issues that a bot might have found doing crazy things. We need to keep optimal S/N on mailing lists, so any bots trying to interact with these lists must be very cautious and damn smart. When I have time to spare and can work on syzbot reports, I am going to a web page where I can see them and select the ones it makes sense to fix. I hate having to set up email filters.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 11:39:13PM -0400, Theodore Y. Ts'o wrote: > On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote: > > From: Eric Biggers > > Date: Wed, 24 Jul 2019 11:37:12 -0700 > > > > > We can argue about what words to use to describe this situation, but > > > it doesn't change the situation itself. > > > > And we should argue about those words because it matters to humans and > > effects how they feel, and humans ultimately fix these bugs. > > > > So please stop with the hyperbole. > > Perhaps it would be better to call them, "syzbot reports". Not all > syzbot reports are bugs. In fact, Dmitry has steadfastly refused to > add features which any basic bug-tracking system would have, claiming > that syzbot should not be a bug-tracking system, and something like > bugzilla should be forcibly imposed on all kernel developers. So I > don't consider syzkaller reports as bugs --- they are just reports. > > In order for developers to want to engage with "syzbot reports", we > need to reduce developer toil which syzbot imposes on developers, such > that it is a net benefit, instead of it being just a source of > annoying e-mails, some of which are actionable, and some of which are > noise. > > In particular, asking developers to figure out which syzbot reports > should be closed, because developers found the problem independently, > and fixed it without hearing about from syzbot first, really isn't a > fair thing to ask. Especially if we can automate away the problem. > > If there is a reproducer, it should be possible to automatically > categorize the reproducer as a reliable reproducer or a flakey one. > If it is a reliable reproducer on version X, and it fails to be > reliably reproduce on version X+N, then it should be able to figure > out that it has been fixed, instead of requesting that a human confirm > it. If you really want a human to look at it, now that syzkaller has > a bisection feature, it should be possible to use the reliable > reproducer to do a negative bisection search to report a candidate > fix. This would significantly reproduce the developer toil imposed as > a tax on developers. And if Dmitry doesn't want to auto-close those > reports that appear to be fixed already, at the very least they should > be down-prioritized on Eric's reports, so people who don't want to > waste their time on "bureaucracy" can do so. > > Cheers, > > - Ted > > P.S. Another criteria I'd suggest down-prioritizing on is, "does it > require root privileges?" After all, since root has so many different > ways of crashing a system already, and if we're all super-busy, we > need to prioritize which reports should be addressed first. > I agree with all this. Fix bisection would be really useful. I think what we'd actually need to do to get decent results, though, is consider many different signals (days since last occurred, repro type, fix bisected, bug bisected, occurred in mainline or not, does the repro work as root, is it clearly a "bad" bug like use-after-free, etc.) and compute an appropriate timeout based on that. However, I'd like to emphasize that in my reminder emails, I've *already* considered many of these factors when sorting the bug reports, and in particular the bugs/reports that have been seen recently are strongly weighted towards being listed first, especially if they were seen in mainline. In this particular reminder email, for example, the first 18 bugs/reports have *all* been seen in the last 4 days. These first 18 bugs/reports are ready to be worked on and fixed now. It's unclear to me what is most impeding this. Is it part of the syzbot process? Bad reproducers? Too much noise? Or is it no funding? Not enough qualified people? No maintainers? Not enough reminders? Lack of CVEs and demonstrable exploits? What is most impeding these 18 bugs from being fixed? - Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote: > From: Eric Biggers > Date: Wed, 24 Jul 2019 11:37:12 -0700 > > > We can argue about what words to use to describe this situation, but > > it doesn't change the situation itself. > > And we should argue about those words because it matters to humans and > effects how they feel, and humans ultimately fix these bugs. > > So please stop with the hyperbole. Perhaps it would be better to call them, "syzbot reports". Not all syzbot reports are bugs. In fact, Dmitry has steadfastly refused to add features which any basic bug-tracking system would have, claiming that syzbot should not be a bug-tracking system, and something like bugzilla should be forcibly imposed on all kernel developers. So I don't consider syzkaller reports as bugs --- they are just reports. In order for developers to want to engage with "syzbot reports", we need to reduce developer toil which syzbot imposes on developers, such that it is a net benefit, instead of it being just a source of annoying e-mails, some of which are actionable, and some of which are noise. In particular, asking developers to figure out which syzbot reports should be closed, because developers found the problem independently, and fixed it without hearing about from syzbot first, really isn't a fair thing to ask. Especially if we can automate away the problem. If there is a reproducer, it should be possible to automatically categorize the reproducer as a reliable reproducer or a flakey one. If it is a reliable reproducer on version X, and it fails to be reliably reproduce on version X+N, then it should be able to figure out that it has been fixed, instead of requesting that a human confirm it. If you really want a human to look at it, now that syzkaller has a bisection feature, it should be possible to use the reliable reproducer to do a negative bisection search to report a candidate fix. This would significantly reproduce the developer toil imposed as a tax on developers. And if Dmitry doesn't want to auto-close those reports that appear to be fixed already, at the very least they should be down-prioritized on Eric's reports, so people who don't want to waste their time on "bureaucracy" can do so. Cheers, - Ted P.S. Another criteria I'd suggest down-prioritizing on is, "does it require root privileges?" After all, since root has so many different ways of crashing a system already, and if we're all super-busy, we need to prioritize which reports should be addressed first.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote: > From: Eric Biggers > Date: Wed, 24 Jul 2019 11:37:12 -0700 > > > We can argue about what words to use to describe this situation, but > > it doesn't change the situation itself. > > And we should argue about those words because it matters to humans and > effects how they feel, and humans ultimately fix these bugs. > > So please stop with the hyperbole. > > Thank you. Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the last 7 days (90.1% with reproducers). Of those, 59 were reported over 3 months ago (89.8% with reproducers). Of those, 12 were reported over a year ago (83.3% with reproducers). No opinion on whether those are small/medium/large numbers, in case it would hurt someone's feelings. These numbers do *not* include bugs that are still valid but weren't seen on mainline in last 7 days, e.g.: - Bugs that are seen only rarely, so by chance weren't seen in last 7 days. - Bugs only in linux-next and/or subsystem branches. - Bugs that were seen in mainline more than 7 days ago, and then only on linux-next or subsystem branch in last 7 days. - Bugs that stopped being seen due to a change in syzkaller. - Bugs that stopped being seen due to a change in kernel config. - Bugs that stopped being seen due to other environment changes such as kernel command line parameters. - Bugs that stopped being seen due to a kernel change that hid the bug but didn't actually fix it, i.e. still reachable in other ways. Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers Date: Wed, 24 Jul 2019 11:37:12 -0700 > We can argue about what words to use to describe this situation, but > it doesn't change the situation itself. And we should argue about those words because it matters to humans and effects how they feel, and humans ultimately fix these bugs. So please stop with the hyperbole. Thank you.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 08:52:54PM +0200, 'Eric Dumazet' via syzkaller-bugs wrote: > On Wed, Jul 24, 2019 at 8:37 PM Eric Biggers wrote: > > > A huge number of valid open bugs are not being fixed, which is a fact. We > > can > > argue about what words to use to describe this situation, but it doesn't > > change > > the situation itself. > > > > What is your proposed solution? > > syzbot sends emails, plenty of them, with many wrong bisection > results, increasing the noise. > > If nobody is interested, I am not sure sending copies of them > repeatedly will be of any help. > > Maybe a simple monthly reminder with one URL to go to the list of bugs > would be less intrusive. > The bogus bisection results is a known issue (which I'm trying to convince Dmitry is important enough to fix...), which is why I manually reviewed all of them and discarded out all the obviously incorrect ones. My reminders only include manually reviewed bisection results. Obviously there will still be some looked plausible but are actualy wrong, but I suspect the accuracy is around 80-90% rather than the 40-50% of the raw syzbot bisection results. - Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 8:37 PM Eric Biggers wrote: > A huge number of valid open bugs are not being fixed, which is a fact. We can > argue about what words to use to describe this situation, but it doesn't > change > the situation itself. > > What is your proposed solution? syzbot sends emails, plenty of them, with many wrong bisection results, increasing the noise. If nobody is interested, I am not sure sending copies of them repeatedly will be of any help. Maybe a simple monthly reminder with one URL to go to the list of bugs would be less intrusive.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 11:12:25AM -0700, David Miller wrote: > From: Eric Biggers > Date: Wed, 24 Jul 2019 09:30:14 -0700 > > > On Wed, Jul 24, 2019 at 08:39:05AM +0200, Eric Dumazet wrote: > >> Some of the bugs have been fixed already, before syzbot found them. > >> > >> Why force human to be gentle to bots and actually replying to them ? > >> > >> I usually simply wait that syzbot is finding the bug does not repro > >> anymore, > >> but now if you send these emails, we will have even more pressure on us. > >> > > > > First, based on experience, I'd guess about 30-45 of these are still valid. > > 17 > > were seen in mainline in the last week, but some others are valid too. The > > ones > > most likely to still be valid are at the beginning of the list. So let's > > try > > not use the presence of outdated bugs as an excuse not to fix current bugs. > > So about half of the bugs we are to look at are already fixed and thus > noise, even as estimated by you. > > I agree with Eric, these "reminders" are bad for the people you > actually want to work on fixing these bugs. Well, the problem is that no one knows for sure which bugs are fixed and which aren't. To be certain, a human needs to review each bug. A bot can only guess. Note that the bugs in my reminders are already automatically prioritized by how likely they are to still be valid, important, actionable. So one simply needs to start at the beginning of the list if they want to focus on those types of bugs. Isn't this helpful? > > > Since the kernel community is basically in continuous bug bankruptcy and > > lots of > > I don't like this hyperbole. Please present facts and information we > can actually use to improve the kernel development and bug fixing > process. > A huge number of valid open bugs are not being fixed, which is a fact. We can argue about what words to use to describe this situation, but it doesn't change the situation itself. What is your proposed solution? - Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers Date: Wed, 24 Jul 2019 09:30:14 -0700 > On Wed, Jul 24, 2019 at 08:39:05AM +0200, Eric Dumazet wrote: >> Some of the bugs have been fixed already, before syzbot found them. >> >> Why force human to be gentle to bots and actually replying to them ? >> >> I usually simply wait that syzbot is finding the bug does not repro anymore, >> but now if you send these emails, we will have even more pressure on us. >> > > First, based on experience, I'd guess about 30-45 of these are still valid. > 17 > were seen in mainline in the last week, but some others are valid too. The > ones > most likely to still be valid are at the beginning of the list. So let's try > not use the presence of outdated bugs as an excuse not to fix current bugs. So about half of the bugs we are to look at are already fixed and thus noise, even as estimated by you. I agree with Eric, these "reminders" are bad for the people you actually want to work on fixing these bugs. > Since the kernel community is basically in continuous bug bankruptcy and lots > of I don't like this hyperbole. Please present facts and information we can actually use to improve the kernel development and bug fixing process. Thank you.
Re: Reminder: 99 open syzbot bugs in net subsystem
On Wed, Jul 24, 2019 at 08:39:05AM +0200, Eric Dumazet wrote: > > > On 7/24/19 3:38 AM, Eric Biggers wrote: > > [This email was generated by a script. Let me know if you have any > > suggestions > > to make it better, or if you want it re-generated with the latest status.] > > > > Of the currently open syzbot reports against the upstream kernel, I've > > manually > > marked 99 of them as possibly being bugs in the net subsystem. This > > category > > only includes the networking bugs that I couldn't assign to a more specific > > component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've > > listed > > these reports below, sorted by an algorithm that tries to list first the > > reports > > most likely to be still valid, important, and actionable. > > > > Of these 99 bugs, 17 were seen in mainline in the last week. > > > > Of these 99 bugs, 4 were bisected to commits from the following people: > > > > Florian Westphal > > Ilya Maximets > > Eric Dumazet > > David Ahern > > > > If you believe a bug is no longer valid, please close the syzbot report by > > sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the > > original thread, as explained at https://goo.gl/tpsmEJ#status > > > > If you believe I misattributed a bug to the net subsystem, please let me > > know, > > and if possible forward the report to the correct people or mailing list. > > > > Some of the bugs have been fixed already, before syzbot found them. > > Why force human to be gentle to bots and actually replying to them ? > > I usually simply wait that syzbot is finding the bug does not repro anymore, > but now if you send these emails, we will have even more pressure on us. > First, based on experience, I'd guess about 30-45 of these are still valid. 17 were seen in mainline in the last week, but some others are valid too. The ones most likely to still be valid are at the beginning of the list. So let's try not use the presence of outdated bugs as an excuse not to fix current bugs. Second, all these bug reports are still open, regardless of whether reminders are sent or not. I think you're really suggesting that possibly outdated bug reports should be automatically invalidated by syzbot. syzbot already does that for bugs with no reproducer. However, that still leaves a lot of outdated bugs with reproducers. Since the kernel community is basically in continuous bug bankruptcy and lots of syzbot reports are being ignored anyway, I'm in favor of making the invalidation criteria more aggressive, so we can best focus people's efforts. I understand that Dmitry has been against this though, since a significant fraction of bugs that syzbot stopped hitting for some reason actually turn out to be still valid. But we probably have no choice. So I suggest we agree on new criteria for invalidating bugs. I'd suggest assigning a timeout to each bug, based on attributes like "seen in mainline?", "reproducer type", "bisected?", "does it look like a 'bad' crash (e.g. use-after-free)"; similar to the algorithm I'm using to sort the bugs when sorting these reminders. I.e., bugs most likely to still be valid, important, and actionable get longest timeouts. Then if no crash or activity was seen in the timeout, the bug is closed. Any thoughts from anyone? - Eric
Re: Reminder: 99 open syzbot bugs in net subsystem
On 7/24/19 3:38 AM, Eric Biggers wrote: > [This email was generated by a script. Let me know if you have any > suggestions > to make it better, or if you want it re-generated with the latest status.] > > Of the currently open syzbot reports against the upstream kernel, I've > manually > marked 99 of them as possibly being bugs in the net subsystem. This category > only includes the networking bugs that I couldn't assign to a more specific > component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've > listed > these reports below, sorted by an algorithm that tries to list first the > reports > most likely to be still valid, important, and actionable. > > Of these 99 bugs, 17 were seen in mainline in the last week. > > Of these 99 bugs, 4 were bisected to commits from the following people: > > Florian Westphal > Ilya Maximets > Eric Dumazet > David Ahern > > If you believe a bug is no longer valid, please close the syzbot report by > sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the > original thread, as explained at https://goo.gl/tpsmEJ#status > > If you believe I misattributed a bug to the net subsystem, please let me know, > and if possible forward the report to the correct people or mailing list. > Some of the bugs have been fixed already, before syzbot found them. Why force human to be gentle to bots and actually replying to them ? I usually simply wait that syzbot is finding the bug does not repro anymore, but now if you send these emails, we will have even more pressure on us.
Reminder: 99 open syzbot bugs in net subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 99 of them as possibly being bugs in the net subsystem. This category only includes the networking bugs that I couldn't assign to a more specific component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 99 bugs, 17 were seen in mainline in the last week. Of these 99 bugs, 4 were bisected to commits from the following people: Florian Westphal Ilya Maximets Eric Dumazet David Ahern If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the net subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: unregister_netdevice: waiting for DEV to become free (2) Last occurred: 0 days ago Reported: 342 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=bae9a2236bfede42cf3d219e6bf6740c583568a4 Original thread: https://lkml.kernel.org/lkml/56268e05737dc...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 27 replies; the last was 80 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+30209ea299c09d878...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/56268e05737dc...@google.com Title: kernel BUG at net/core/skbuff.c:LINE! (3) Last occurred: 1 day ago Reported: 537 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00 Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/001a114372a6074e6505642b7f72%40google.com This bug has a C reproducer. For some reason the original report email for this bug is missing from the LKML archive at lore.kernel.org, so my script couldn't check whether anyone has replied to it or not. The Google Groups link above should still work, though. Also try searching for the bug title. Title: KMSAN: uninit-value in __netif_receive_skb_core Last occurred: 0 days ago Reported: 467 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=0c8e5c99b3db338c8956fcb7231eb1f7e2d707f9 Original thread: https://lkml.kernel.org/lkml/94eb2c059ce01f643c0569a22...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 3 replies; the last was 466 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/94eb2c059ce01f643c0569a22...@google.com Title: KMSAN: uninit-value in ip6_parse_tlv Last occurred: 0 days ago Reported: 306 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=a446d3718ee6322911a0c6d34db57909e1838fe7 Original thread: https://lkml.kernel.org/lkml/30779c057653b...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+f08ac29f2ac8aea19...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/30779c057653b...@google.com
