linux-kernel - Re: [PATCH] p54usb: Fix race between disconnect and firmware loading

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] [day] [month] [year] [list]

Message-Id: <20190625044320.6BB25608CE@smtp.codeaurora.org>
Date:   Tue, 25 Jun 2019 04:43:20 +0000 (UTC)
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Christian Lamparter <chunkeey@...il.com>,
        syzbot <syzbot+200d4bb11b23d929335f@...kaller.appspotmail.com>,
        <davem@...emloft.net>, <andreyknvl@...gle.com>,
        <syzkaller-bugs@...glegroups.com>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        <linux-wireless@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] p54usb: Fix race between disconnect and firmware loading

Alan Stern <stern@...land.harvard.edu> wrote:

> 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@...land.harvard.edu>
> Reported-and-tested-by: syzbot+200d4bb11b23d929335f@...kaller.appspotmail.com
> CC: <stable@...r.kernel.org>
> Acked-by: Christian Lamparter <chunkeey@...il.com>

Patch applied to wireless-drivers-next.git, thanks.

6e41e2257f10 p54usb: Fix race between disconnect and firmware loading

-- 
https://patchwork.kernel.org/patch/10951527/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches