Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752685AbcDZWTc (ORCPT ); Tue, 26 Apr 2016 18:19:32 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51093 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752401AbcDZWTb (ORCPT ); Tue, 26 Apr 2016 18:19:31 -0400 Date: Tue, 26 Apr 2016 15:16:01 -0700 From: Greg KH To: changbin.du@intel.com Cc: stern@rowland.harvard.edu, baolu.lu@linux.intel.com, chasemetzger15@gmail.com, balbi@ti.com, kborer@gmail.com, mjg59@coreos.com, jun.li@freescale.com, Robert.Schlabbach@gmx.net, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, tonyb@cybernetics.com, joe.lawrence@stratus.com Subject: Re: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device Message-ID: <20160426221601.GA23085@kroah.com> References: <1457428517-3099-1-git-send-email-changbin.du@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1457428517-3099-1-git-send-email-changbin.du@intel.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3172 Lines: 93 On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin.du@intel.com wrote: > From: "Du, Changbin" > > This is a reworked patch based on reverted commit d8f00cd685f5 ("usb: > hub: do not clear BOS field during reset device"). > > The privious one caused double mem-free if run to re_enumerate label. > New patch title changed to distinguish from old one. And I have tested > it with memory debugging options. > > In function usb_reset_and_verify_device, the old BOS descriptor may > still be used before allocating a new one. (usb_disable_lpm function > uses it under the situation that it fails at usb_disable_link_state.) > So we cannot set the udev->bos to NULL before that, just keep what it > was. It will be overwrite when allocating a new one. > > How to reproduce: > 1. connect one usb3 hub to xhci port. > 2. connect several lpm-capable super-speed usb disk to the hub. > 3. copy big files to the usb disks. > 4. disconnect the hub and repeat step 1-4. > > Crash log: > BUG: unable to handle kernel NULL pointer dereference at > 0000000000000010 > IP: [] usb_enable_link_state+0x2d/0x2f0 > Call Trace: > [] ? usb_set_lpm_timeout+0x12b/0x140 > [] usb_enable_lpm+0x81/0xa0 > [] usb_disable_lpm+0xa8/0xc0 > [] usb_unlocked_disable_lpm+0x2c/0x50 > [] usb_reset_and_verify_device+0xc3/0x710 > [] ? usb_sg_wait+0x13d/0x190 > [] usb_reset_device+0x133/0x280 > [] usb_stor_port_reset+0x61/0x70 > [] usb_stor_invoke_transport+0x88/0x520 > > Signed-off-by: Du, Changbin > --- > drivers/usb/core/hub.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) Is this patch still needed? I thought we had some other fix in this area... confused, greg k-h > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 51b43691..27444e5 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -5401,7 +5401,6 @@ static int usb_reset_and_verify_device(struct usb_device *udev) > } > > bos = udev->bos; > - udev->bos = NULL; > > for (i = 0; i < SET_CONFIG_TRIES; ++i) { > > @@ -5494,13 +5493,18 @@ done: > usb_set_usb2_hardware_lpm(udev, 1); > usb_unlocked_enable_lpm(udev); > usb_enable_ltm(udev); > - usb_release_bos_descriptor(udev); > - udev->bos = bos; > + /* release the new BOS descriptor allocated by hub_port_init() */ > + if (udev->bos != bos) { > + usb_release_bos_descriptor(udev); > + udev->bos = bos; > + } > return 0; > > re_enumerate: > - usb_release_bos_descriptor(udev); > - udev->bos = bos; > + if (udev->bos != bos) { > + usb_release_bos_descriptor(udev); > + udev->bos = bos; > + } > re_enumerate_no_bos: > /* LPM state doesn't matter when we're about to destroy the device. */ > hub_port_logical_disconnect(parent_hub, port1); > -- > 2.5.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html