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]

Date:   Wed, 01 Feb 2017 07:24:44 +0000
From:   Ajay Kaher <ajay.kaher@...sung.com>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
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

>> 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.

>> 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).

thanks,

ajay kaher

--------- Original Message ---------
Sender : gregkh@...uxfoundation.org <gregkh@...uxfoundation.org>
Date   : 2017-01-31 12:31 (GMT+5:30)
Title  : 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

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +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?

And what do you mean exactly by "(proprietary devices)"?

> 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?

thanks,

greg k-h

Thanks and Regards,
Ajay Kaher