linux-kernel - Re: KASAN: use-after-free Read in hci_chan

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: <YL4BAKHPZqH6iPdP@kroah.com>
Date:   Mon, 7 Jun 2021 13:20:32 +0200
From:   Greg KH <greg@...ah.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     SyzScope <syzscope@...il.com>,
        syzbot <syzbot+305a91e025a73e4fd6ce@...kaller.appspotmail.com>,
        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,
        kernel-hardening@...ts.openwall.com
Subject: Re: KASAN: use-after-free Read in hci_chan_del

On Mon, Jun 07, 2021 at 12:21:12PM +0200, Jason A. Donenfeld wrote:
> Hi SyzScope,
> 
> On Fri, May 28, 2021 at 02:12:01PM -0700, SyzScope wrote:
>  
> > The bug was reported by syzbot first in Aug 2020. Since it remains 
> > unpatched to this date, we have conducted some analysis to determine its 
> > security impact and root causes, which hopefully can help with the 
> > patching decisions.
> > Specifically, we find that even though it is labeled as "UAF read" by 
> > syzbot, it can in fact lead to double free and control flow hijacking as 
> > well. Here is our analysis below (on this kernel version: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af5043c89a8ef6b6949a245fff355a552eaed240)
> > 
> > ----------------------------- Root cause analysis: 
> > --------------------------
> > The use-after-free bug happened because the object has two different 
> > references. But when it was freed, only one reference was removed, 
> > allowing the other reference to be used incorrectly.
> > [...]
> 
> Thank you very much for your detailed analysis. I think this is very
> valuable work, and I appreciate you doing it. I wanted to jump in to
> this thread here so as not to discourage you, following Greg's hasty
> dismissal. The bad arguments made I've seen have been something like:
> 
> - Who cares about the impact? Bugs are bugs and these should be fixed
>   regardless. Severity ratings are a waste of time.
> - Spend your time writing patches, not writing tools to discover
>   security issues.
> - This doesn't help my interns.
> - "research project" scare quotes.
> 
> I think this entire set of argumentation is entirely bogus, and I really
> hope it doesn't dissuade you from continuing to conduct useful research
> on the kernel.

Ok, I'd like to apologize if that was the attitude that came across
here, as I did not mean it that way.

What I saw here was an anonymous email, saying "here is a whole bunch of
information about a random syzbot report that means you should fix this
sooner!"  When there's a dump this big of "information", but no patch,
that's almost always a bad sign that the information really isn't all
that good, otherwise the author would have just sent a patch to fix it.

We are drowning in syzbot bugs at the moment, with almost no one helping
to fix them.  So much so that the only people I know of working on this
are the interns with with the LF has funded because no other company
seems willing to help out with this task.

That's not the syzbot author's fault, it's the fault of every other
company that relies on Linux at the moment.  By not providing time for
their engineers to fix these found bugs, and only add new features, it's
not going to get any better.

So this combined two things I'm really annoyed at, anonymous
contributions combined with "why are you not fixing this" type of
a report.  Neither of which were, in the end, actually helpful to us.

I'm not asking for any help for my interns, nor am I telling anyone what
to work on.  I am saying please don't annoy the maintainers who are
currently overwhelmed at the moment with additional reports of this type
when they obviously can not handle the ones that we have.

Working with the syzbot people to provide a more indepth analysis of the
problem is wonderful, and will go a long way toward helping being able
to do semi-automatic fixing of problems like this, which would be
wonderful.  But how were we supposed to know this anonymous gmail
account, with a half-completed google pages web site was not just a
troll trying to waste our time?

What proof did we have that this really was a correct report if a real
person didn't even provide their name to it?

thanks,

greg k-h