Thanks, that fixes it. Tested on 4.5.0-rc5 and 3.18.27. Just to be clear, I tested it *without* reverting d8f00cd685f5. So this patch is in addition to d8f00cd685f5 instead of replacing it. Tested-by: Tony Battersby <tonyb@xxxxxxxxxxxxxxx> On 02/21/2016 09:27 PM, Du, Changbin wrote: > Thanks for reporting, Tony. It was remiss of me. > There is another BOS free operation in label re_enumerate. This cause a double-free of BOS. > USB2 doesn't have BOS desc, so you cannot reproduce it. > > I am on a travel. It is appreciated if you can help try below fix. > > Hi, Greg, I will commit a final patch once returned from travel. > > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -5501,8 +5501,10 @@ done: > return 0; > > re_enumerate: > - usb_release_bos_descriptor(udev); > - udev->bos = bos; > + if (udev->bos != bos) { > + usb_release_bos_descriptor(udev); > + udev->bos = bos; > + } > > Best Regards, > Du, Changbin > >> On Fri, Feb 19, 2016 at 09:39:57AM -0500, Tony Battersby wrote: >>> This upstream commit is causing an oops: >>> d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device") >>> >>> This patch has already been included in several -stable kernels. Here >>> are the affected kernels: >>> 4.5.0-rc4 (current git) >>> 4.4.2 >>> 4.3.6 (currently in review) >>> 4.1.18 >>> 3.18.27 >>> 3.14.61 >>> >>> How to reproduce the problem: >>> Boot kernel with slub debugging enabled (otherwise memory corruption >>> will cause random oopses later instead of immediately) >>> Plug in USB 3.0 disk to xhci USB 3.0 port >>> dd if=/dev/sdc of=/dev/null bs=65536 >>> (where /dev/sdc is the USB 3.0 disk) >>> Unplug USB cable while dd is still going >>> Oops is immediate: >> Not good, thanks for letting us know. I've now reverted this and will >> get the fix into 4.5-rc6. >> >> greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html