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

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]

Date:   Thu, 28 Nov 2019 12:25:05 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Oliver Neukum <oneukum@...e.com>
cc:     syzbot <syzbot+9ca7a12fd736d93e0232@...kaller.appspotmail.com>,
        <andreyknvl@...gle.com>, <hverkuil@...all.nl>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        <linux-media@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>, <mchehab@...nel.org>,
        <syzkaller-bugs@...glegroups.com>
Subject: Re: KASAN: use-after-free Read in si470x_int_in_callback (2)

On Thu, 28 Nov 2019, Oliver Neukum wrote:

> Am Mittwoch, den 27.11.2019, 16:11 -0500 schrieb Alan Stern:
> > Oliver:
> > 
> > Make of this what you will...
> 
> Hi,
> 
> first, thank you. Second, this is teaching me to question my
> assumptions. There is no disconnect at all. We are busy looping
> in the error handler as we have virtual hardware in this test,
> which can execute an URB without waiting for hardware.
> 
> So should we kill error handling for this case?

Okay.  First of all, we must recognize that these syzbot tests have
encountered two separate bugs.  The first is the one fixed in your
original patches (the use-after-free).  This bug needs no discussion;
it looks like your patch fixes it.

The second bug is the CPU starvation caused by the tight resubmit loop
in the completion handler.  It is the reason why you kept getting
failure reports back from syzbot.  It is to some extent a misleading
result, related to the fact that dummy-hcd doesn't use real hardware,
as you noted.

Nevertheless, the fix I posted is appropriate.  I posed this question
to Greg KH some weeks ago, and he pointed out that after some
discussion on the mailing list, people had generally agreed that
drivers should not blindly resubmit URBs when they get an unrecognized
error status.  In this situation, error recovery has to occur at a
higher level (for example, the user could unplug the device and then
plug it in again).

So even though with real hardware this tight resubmit loop might not
end up using all the available CPU time, not resubmitting is still the
right approach.

Alan Stern