[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5b38eb74-43d0-c7d7-88e1-103a4f82333f@gmail.com>
Date: Wed, 31 Jul 2019 09:13:11 -0600
From: David Ahern <dsahern@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>, dvyukov@...gle.com,
netdev@...r.kernel.org, fw@...len.de, i.maximets@...sung.com,
edumazet@...gle.com, linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: 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 <dsahern@...il.com>
Date: Thu May 23 03:27:55 2019 +0000
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.
Powered by blists - more mailing lists