linux-kernel - Re: [PATCH] Prevent race condition between USB authorisation and USB discovery events

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.1812171114170.1630-100000@iolanthe.rowland.org>
Date:   Mon, 17 Dec 2018 11:21:55 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Andrew Worsley <amworsley@...il.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Nicolas Boichat <drinkcat@...omium.org>,
        Jon Flatley <jflat@...omium.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Bin Liu <b-liu@...com>, Benson Leung <bleung@...omium.org>,
        "open list:USB SUBSYSTEM" <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Prevent race condition between USB authorisation and
 USB discovery events

On Mon, 17 Dec 2018, Andrew Worsley wrote:

> A sysfs driven USB authorisation change can trigger a usb_set_configuration
> while a hub_event worker thread is running. This can result in a USB device
> being disabled just after it was configured and bringing down all the
> devices and impacting hardware and user processes that were established on
> top of this these interfaces. In some cases the USB disable never completed
> and the whole system hung.

Can you be more specific about this?  Disabling a USB device shouldn't
cause these kinds of problems, regardless of whether or not the device
was just configured.

> At my work I had an occasional hang due to this race condition. Roughly 1
> in 50 boots had the race occurrence and 1 in 4 of those resulted in a hang.
> This patch fixed the problem and I had no problems (spurious disables
> or hangs) in 750+ boots.

usb_authorize_device, usb_deauthorize_device, and hub_event all acquire 
the device mutex.  Why should adding another mutex make any difference?

In fact there's an actual disadvantage: Making hub_event acquire a
global mutex will prevent us from handling multiple hubs concurrently.  
Although we don't do this now, we might want to in the future.

Alan Stern