From: Kalle Valo <kvalo@codeaurora.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Christian Lamparter <chunkeey@gmail.com>,
syzbot <syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com>,
<davem@davemloft.net>, <andreyknvl@google.com>,
<syzkaller-bugs@googlegroups.com>,
Kernel development list <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading
Date: Tue, 28 May 2019 15:11:34 +0300 [thread overview]
Message-ID: <8736kyvkw9.fsf@purkki.adurom.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1905201042110.1498-100000@iolanthe.rowland.org> (Alan Stern's message of "Mon, 20 May 2019 10:44:21 -0400 (EDT)")
Alan Stern <stern@rowland.harvard.edu> writes:
> The syzbot fuzzer found a bug in the p54 USB wireless driver. The
> issue involves a race between disconnect and the firmware-loader
> callback routine, and it has several aspects.
>
> One big problem is that when the firmware can't be loaded, the
> callback routine tries to unbind the driver from the USB _device_ (by
> calling device_release_driver) instead of from the USB _interface_ to
> which it is actually bound (by calling usb_driver_release_interface).
>
> The race involves access to the private data structure. The driver's
> disconnect handler waits for a completion that is signalled by the
> firmware-loader callback routine. As soon as the completion is
> signalled, you have to assume that the private data structure may have
> been deallocated by the disconnect handler -- even if the firmware was
> loaded without errors. However, the callback routine does access the
> private data several times after that point.
>
> Another problem is that, in order to ensure that the USB device
> structure hasn't been freed when the callback routine runs, the driver
> takes a reference to it. This isn't good enough any more, because now
> that the callback routine calls usb_driver_release_interface, it has
> to ensure that the interface structure hasn't been freed.
>
> Finally, the driver takes an unnecessary reference to the USB device
> structure in the probe function and drops the reference in the
> disconnect handler. This extra reference doesn't accomplish anything,
> because the USB core already guarantees that a device structure won't
> be deallocated while a driver is still bound to any of its interfaces.
>
> To fix these problems, this patch makes the following changes:
>
> Call usb_driver_release_interface() rather than
> device_release_driver().
>
> Don't signal the completion until after the important
> information has been copied out of the private data structure,
> and don't refer to the private data at all thereafter.
>
> Lock udev (the interface's parent) before unbinding the driver
> instead of locking udev->parent.
>
> During the firmware loading process, take a reference to the
> USB interface instead of the USB device.
>
> Don't take an unnecessary reference to the device during probe
> (and then don't drop it during disconnect).
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
> CC: <stable@vger.kernel.org>
>
> ---
>
>
> [as1899]
>
>
> drivers/net/wireless/intersil/p54/p54usb.c | 43 ++++++++++++-----------------
> 1 file changed, 18 insertions(+), 25 deletions(-)
The correct prefix is "p54:", but I can fix that during commit.
> Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
> ===================================================================
> --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c
> +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c
> @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb");
> MODULE_FIRMWARE("isl3886usb");
> MODULE_FIRMWARE("isl3887usb");
>
> +static struct usb_driver p54u_driver;
How is it safe to use static variables from a wireless driver? For
example, what if there are two p54 usb devices on the host? How do we
avoid a race in that case?
--
Kalle Valo
next prev parent reply other threads:[~2019-05-28 12:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 11:16 KASAN: use-after-free Read in p54u_load_firmware_cb syzbot
2019-05-13 10:23 ` syzbot
2019-05-13 13:28 ` Oliver Neukum
2019-05-17 19:21 ` Christian Lamparter
2019-05-17 20:46 ` Alan Stern
2019-05-17 21:01 ` syzbot
2019-05-18 15:13 ` Alan Stern
2019-05-18 15:50 ` syzbot
2019-05-18 16:32 ` Alan Stern
2019-05-18 16:50 ` syzbot
2019-05-18 17:01 ` Alan Stern
2019-05-18 17:36 ` syzbot
2019-05-18 17:49 ` Alan Stern
2019-05-18 18:31 ` syzbot
2019-05-18 20:11 ` Christian Lamparter
2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern
2019-05-24 21:19 ` Christian Lamparter
2019-05-28 12:11 ` Kalle Valo [this message]
2019-05-28 14:17 ` Alan Stern
2019-05-28 14:29 ` Kalle Valo
2019-06-25 4:43 ` [PATCH] p54usb: " Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736kyvkw9.fsf@purkki.adurom.net \
--to=kvalo@codeaurora.org \
--cc=andreyknvl@google.com \
--cc=chunkeey@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).