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.1911281225340.19734-100000@netrider.rowland.org>
Date:   Thu, 28 Nov 2019 12:33:42 -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 Thu, 28 Nov 2019, Oliver Neukum wrote:

> Hi,
> 
> it is a bit awkward to complain here, as your patch tests as correct
> while mine didn't, but this is a race condition.
> You can't guarantee that urb->status != 0.
> The kill may happen while the completion handler is running for
> a successful transfer.
> 
> I really appreciate your help, but I must understand what is going
> wrong here. You are stopping the resubmit, but how could the resubmit
> ever have not failed?

You probably have figured all this out already, but I'll answer anyway.

The code I changed doesn't race with the error condition you were 
concerned about.  The two are independent, and it doesn't matter if the 
kill happens while the completion handler is running.

In the case my patch addresses, the resubmit does not fail.  Rather, it
succeeds but then the URB completes with a -EPROTO error.  The problem
is that the completion handler then resubmits the URB again, and it
completes again with the same error, right away, in a tight loop --
which prevents the CPU from executing any other code.  The way to fix
the problem is to break the loop by not resubmitting, which is what the
patch does.

Alan Stern