From: Chung-Geol Kim <chunggeol.kim@samsung.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"mathias.nyman@linux.intel.com" <mathias.nyman@linux.intel.com>,
"stefan.koch10@gmail.com" <stefan.koch10@gmail.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"sergei.shtylyov@cogentembedded.com"
<sergei.shtylyov@cogentembedded.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"sarah.a.sharp@linux.intel.com" <sarah.a.sharp@linux.intel.com>,
"chris.bainbridge@gmail.com" <chris.bainbridge@gmail.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver
Date: Fri, 03 Jun 2016 11:51:25 +0000 (GMT) [thread overview]
Message-ID: <487274449.448981464954680715.JavaMail.weblogic@epmlwas04d> (raw)
>On Fri, 27 May 2016, Chung-Geol Kim wrote:
>
>> >On Fri, May 27, 2016 at 01:38:17AM +0000, Chung-Geol Kim wrote:
>> >> There is a double free problem in the usb driver.
>> >
>> >Which driver?
>> When I using the USB OTG Storage, this issue happened.
>> When remove the OTG Storage, it reproduced sometimes.
>
>> cpu 0 cpu 1
>> ----------------------------------------------------------------------------------------
>> (*Insert USB Storage)
>> usb_create_shared_hcd()
>> kmalloc(primary_hcd)
>> kmalloc(primary_hcd->bandwidth_mutex)
>> ->(primary_hcd->kref==1)
>> usb_get_hcd()
>> ->(primary_hcd->kref==2)
>> usb_create_shared_hcd()
>> kmalloc(hcd->shared_hcd)
>> ->hcd->shared_hcd->bandwidth_mutex=primary->bandwidth_mutex
>> ->primary_hcd->primary_hcd = primary_hcd
>> ->hcd->shared_hcd->primary_hcd = primary_hcd
>> ->(hcd->shared_hcd->kref==1)
>> usb_get_hcd()
>> ->(hcd->shared_hcd->kref==2)
>>
>> usb_get_hcd()
>> ->(hcd->shared_hcd->kref==3)
>
>I don't understand. Why do these actions take place on two different
>CPUs? Aren't the primary_hcd and the shared_hcd structures allocated
>by the same thread, on the same CPU?
Yes, you are right, The presentational errors in order to obtain an understanding of the process.
Therefore, I will be happy to explain again the diagrammatic representation as shown below.
If using usb 3.0 storage(OTG), you can see as below.
==============================================
At *Insert USB(3.0) Storage
sequence <1> --> <5>
==============================================
VOLD
=================================|============
(uevent)
______|___________
|<5> |
| SCSI |
|usb_get_hcd |
|shared_hcd(kref=3)|
|__________________|
___________________ ________|_________
|<2> | |<4> |
|dwc3_otg_sm_work | |dwc3_otg_sm_work |
|usb_get_hcd | |usb_get_hcd |
|primary_hcd(kref=2)| |shared_hcd(kref=2)|
|___________________| |__________________|
_________|_________ ________|_________
|<1> | |<3> |
|New USB BUS #1 | |New USB BUS #2 |
|usb_create_hcd | |usb_create_hcd |
|primary_hcd(kref=1)| |shared_hcd(kref=1)|
| | | |
|bandXX_mutex(alloc)|<-(Link)-bandXX_mutex |
|___________________| |__________________|
==============================================
At *remove USB(3.0) Storage
sequence <1> --> <5> ((Normal Case))
==============================================
VOLD
=================================|============
(uevent)
______|___________
|<1> |
| SCSI |
|usb_put_hcd |
|shared_hcd(kref=2)|
|__________________|
___________________ ________|_________
|<4> | |<2> |
|dwc3_otg_sm_work | |dwc3_otg_sm_work |
|usb_put_hcd | |usb_put_hcd |
|primary_hcd(kref=1)| |shared_hcd(kref=1)|
|___________________| |__________________|
_________|_________ ________|_________
|<5> | |<3> |
|New USB BUS #1 | |New USB BUS #2 |
|hcd_release | |hcd_release |
|primary_hcd(kref=0)| |shared_hcd(kref=0)|
| | | |
|bandXX_mutex(free) | -X-cut off)-bandXX_mutex|
|___________________| |__________________|
----------------------------------------------
>
>> ---------------------------------------------------------------------------------------
>> (*remove USB Storage)
>> usb_release_dev()
>> ->(hcd->shared_hcd-kref==2)
>> usb_release_dev()
>> ->(hcd->shared_hcd-kref==1)
>> usb_release_dev()
>> -> (primary_hcd-kref==1)
>> usb_release_dev()
>> -> (primary_hcd-kref==0)
>> hcd_release()
>> -> kfree(primary_hcd->bandwidth_mutex)
>> -> hcd->shared_hcd->primary_hcd = NULL
>> -> kfree(primary_hcd)
>> usb_release_dev()
>> -> (hcd->shared_hcd-kref==0)
>> hcd_release()
>> -> usb_hcd_is_primary_hcd(hcd->shared_hcd)
>> -> hcd->shared_hcd->primary_hcd already NULL, return 1
>> -> try to double kfree(primary_hcd->bandwidth_mutex)
>
>The same question applies here. Aren't the shared_hcd and primary_hcd
>structures released by the same thread, on the same CPU?
>
>The real bug here is that the shared_hcd is released after the
>primary_hcd. That's what you need to fix.
NO, It 's only depend on vold(scsi) release time.
If the vold later released and is being released first hcd,
Double free happened at <5> as below.
==============================================
At *remove USB(3.0) Storage
sequence <1> --> <5> ((Problem Case))
==============================================
VOLD
=================================|============
(uevent)
______|___________
|<5> |
| SCSI |
|usb_put_hcd |
|shared_hcd(kref=0)|
|*hcd_release |
|bandXX_mutex(free*)|<- double free
|__________________|
___________________ ________|_________
|<3> | |<1> |
|dwc3_otg_sm_work | |dwc3_otg_sm_work |
|usb_put_hcd | |usb_put_hcd |
|primary_hcd(kref=1)| |shared_hcd(kref=2)|
|___________________| |__________________|
_________|_________ ________|_________
|<4> | |<2> |
|New USB BUS #1 | |New USB BUS #2 |
|hcd_release | | |
|primary_hcd(kref=0)| |shared_hcd(kref=1)|
| | | |
|bandXX_mutex(free) |<-(Link)-bandXX_mutex |
|___________________| |__________________|
----------------------------------------------
>> Since hcd->shared_hcd->priary_hcd was Null it didn't reach (hcd == hcd->primary_hcd) in usb_hcd_is_primary_hcd().
>> It returned 1 at since condition !hcd->primary_hcd is met.
>
>> >> --- a/drivers/usb/core/hcd.c
>> >> +++ b/drivers/usb/core/hcd.c
>> >> @@ -2608,7 +2608,7 @@ static void hcd_release(struct kref *kref)
>> >> struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
>> >>
>> >> mutex_lock(&usb_port_peer_mutex);
>> >> - if (usb_hcd_is_primary_hcd(hcd)) {
>> >> + if (hcd == hcd->primary_hcd) {
>> >
>> >That doesn't make sense, usb_hcd_is_primary_hcd() is the same as this
>> >check, what are you changing here?
>>
>> Since hcd->priary_hcd was Null it didn't reach (hcd == hcd->primary_hcd).
>> It returned 1 at since condition !hcd->primary_hcd is met.
>>
>> int usb_hcd_is_primary_hcd(struct usb_hcd *hcd)
>> {
>> if (!hcd->primary_hcd)
>> return 1;
>> return hcd == hcd->primary_hcd;
>> }
>
>That's just a symptom, not the real cause of the bug. You need to fix
>the real cause: the shared_hcd has to be released _before_ the
>primary_hcd.
>
>The right way to do this is to make the shared_hcd take a reference to
>the primary_hcd. This reference should be dropped when hcd_release()
>is called for the shared_hcd.
>
>Alan Stern
>
next reply other threads:[~2016-06-03 11:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 11:51 Chung-Geol Kim [this message]
2016-06-03 14:28 ` Alan Stern
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=487274449.448981464954680715.JavaMail.weblogic@epmlwas04d \
--to=chunggeol.kim@samsung.com \
--cc=chris.bainbridge@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=sarah.a.sharp@linux.intel.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=stefan.koch10@gmail.com \
--cc=stern@rowland.harvard.edu \
/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
all inboxes | Powered by JetHome®