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 linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
