linux-kernel - Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb

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: <20170201090006.GA25372@kroah.com>
Date:   Wed, 1 Feb 2017 10:00:06 +0100
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Ajay Kaher <ajay.kaher@...sung.com>
Cc:     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        AMAN DEEP <aman.deep@...sung.com>,
        HEMANSHU SRIVASTAVA <hemanshu.s@...sung.com>
Subject: Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of
 Race Condition when two USB class drivers try to call init_usb_class
 simultaneously

On Wed, Feb 01, 2017 at 07:24:44AM +0000, Ajay Kaher wrote:
>  
> >> At boot time, probe function of multiple connected devices
> >> (proprietary devices) execute simultaneously.
> >
> >What exactly do you mean here?  How can probe happen "simultaneously"?
> >The USB core prevents this, right?
> 
> I have observed two scenarios to call probe function:
> 
> Scenario #1: Driver inserted and attaching USB Device:
> Yes, you are right, two probes at same time is not happening
> in this scenario.
> 
> Scenario #2: USB Device attached and inserting Driver:
> In this case probe has been called in context of insmod,
> refer following code flow:
> init -> usb_register_driver -> driver_register -> bus_add_driver ->
> driver_attach -> bus_for_each_dev -> __driver_attach ->
> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev
> 
> I have observed the crash in Scenario #2, as two probes executes at
> same time in this scenario. And init_usb_class_mutex lock require to
> prevent race condition.

What about the fact that in __driver_attach() we call device_lock() so
that probe never gets called at the same time for the same device?

Or are you saying that you can load multiple USB modules at the same
time?  If so, how is insmod running on multiple cpus at the same time?
I thought we had a global lock there to prevent that from happening
(i.e. only one module can be loaded at a time.)  Or is that what has
recently changed?

What is causing your modules to be loaded from userspace?  What type of
device is this happening for?  And why haven't we seen this before?
What kernel versions have you had a problem with this?

And what for what drivers specifically?

> >> And because of the following code path race condition happens:
> >> probe->usb_register_dev->init_usb_class
> >
> >Why is this just showing up now, and hasn't been an issue for the decade
> >or so this code has been around?  What changed?
> >
> >> Tested with these changes, and problem has been solved.
> >
> >What changes?
> 
> Tested with my patch (i.e. locking with init_usb_class_mutex).

I don't see a patch here :(

thanks,

greg k-h