lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d37fecad-eed3-5eb8-e30a-ebb912e3a073@gmail.com>
Date:   Sat, 5 Jun 2021 11:12:49 -0700
From:   SyzScope <syzscope@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     davem@...emloft.net, johan.hedberg@...il.com, kuba@...nel.org,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        marcel@...tmann.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: use-after-free Read in hci_chan_del

Hi Greg,

> I do not recall that, sorry, when was that?
We sent an email to security@...nel.org from xzou017@....edu account on 
May 20, the title is "KASAN: use-after-free Read in hci_chan_del has 
dangerous security impact".
> Is that really the reason why syzbot-reported problems are not being
> fixed?  Just because we don't know which ones are more "important"?
>
> As someone who has been managing many interns for a year or so working
> on these, I do not think that is the problem, but hey, what do I know...

Perhaps we misunderstood the problem of syzbot-generated bugs. Our 
understanding is that if a syzbot-generated bug is exploited in the wild 
and/or the exploit code is made publicly available somehow, then the bug 
will be fixed in a prioritized fashion. If our understanding is correct, 
wouldn't it be nice if we, as good guys, can figure out which bugs are 
security-critical and patch them before the bad guys exploit them.

On 05/06/2021 00:43, Greg KH wrote:
> On Fri, Jun 04, 2021 at 10:11:03AM -0700, SyzScope wrote:
>> Hi Greg,
>>
>>> Who is working on and doing this "reseach project"?
>> We are a group of researchers from University of California, Riverside (we
>> introduced ourselves in an earlier email to security@...nel.org if you
>> recall).
> I do not recall that, sorry, when was that?
>
>>   Please allow us to articulate the goal of our research. We'd be
>> happy to hear your feedback and suggestions.
>>
>>> And what is it
>>> doing to actually fix the issues that syzbot finds?  Seems like that
>>> would be a better solution instead of just trying to send emails saying,
>>> in short "why isn't this reported issue fixed yet?"
>>  From our limited understanding, we know a key problem with syzbot bugs is
>> that there are too many of them - more than what can be handled by
>> developers and maintainers. Therefore, it seems some form of prioritization
>> on bug fixing would be helpful. The goal of the SyzScope project is to
>> *automatically* analyze the security impact of syzbot bugs, which helps with
>> prioritizing bug fixes. In other words, when a syzbot bug is reported, we
>> aim to attach a corresponding security impact "signal" to help developers
>> make an informed decision on which ones to fix first.
> Is that really the reason why syzbot-reported problems are not being
> fixed?  Just because we don't know which ones are more "important"?
>
> As someone who has been managing many interns for a year or so working
> on these, I do not think that is the problem, but hey, what do I know...
>
>> Currently,  SyzScope is a standalone prototype system that we plan to open
>> source. We hope to keep developing it to make it more and more useful and
>> have it eventually integrated into syzbot (we are in talks with Dmitry).
>>
>> We are happy to talk more offline (perhaps even in a zoom meeting if you
>> would like). Thanks in advance for any feedback and suggestions you may
>> have.
> Meetings are not really how kernel development works, sorry.
>
> At the moment, these emails really do not seem all that useful, trying
> to tell other people what to do does not get you very far when dealing
> with people who you have no "authority" over...
>
> Technical solutions to human issues almost never work, however writing a
> procmail filter to keep me from having to see these will work quite well :)
>
> good luck!
>
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ