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]

Message-ID: <Pine.LNX.4.44L0.1911221506490.1511-100000@iolanthe.rowland.org>
Date:   Fri, 22 Nov 2019 15:12:55 -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>,
        <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <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 Fri, 22 Nov 2019, Oliver Neukum wrote:

> Am Freitag, den 22.11.2019, 10:35 -0500 schrieb Alan Stern:
> > On Fri, 22 Nov 2019, syzbot wrote:
> > 
> > > Hello,
> > > 
> > > syzbot has tested the proposed patch but the reproducer still triggered  
> > > crash:
> > > INFO: rcu detected stall in dummy_timer
> > > 
> > > radio-si470x 1-1:0.0: non-zero urb status (-71)
> > > radio-si470x 4-1:0.0: non-zero urb status (-71)
> > > radio-si470x 3-1:0.0: non-zero urb status (-71)
> > 
> > Oliver:
> > 
> > The reason for this stall is because the driver goes into a tight
> > resubmit loop when the interrupt URB completes with an unrecognized
> > error status.  Instead, the driver should log an error message and
> > avoid resubmitting.  Error recovery can be done at a higher level.
> > 
> > In other words, change the
> > 
> > 			goto resubmit; /* Maybe we can recover. */
> > 
> > line in the completion handler into a return.

(I guess you also should clear the int_in_running flag, although the 
callback routine doesn't do that in the case of -ENOENT, -ECONNRESET, 
or -ESHUTDOWN.)

> 
> I thought so, too. That is why I poisoned the URB. Am I dense?

Poisoning the URB should work -- if you do it in the right place.  The
probe routine might not be good enough; an unrecognized error can occur
after the probe has succeeded.

Did you modify si470x_int_in_callback()?  That's where the tight loop
is.

Alan Stern