RE: Possible race in 4.14 xhci stack

["Schmid, Carsten" <Carsten_Schmid@mentor.com>]

Hi Mathias,

thanks, that's exactly the fix/workaround/cure I wanted to do.
Will fix it this way 😊

Have a nice vacation.

Best regards
Carsten

-----Original Message-----
From: Mathias Nyman <mathias.nyman@linux.intel.com>
Sent: Freitag, 23. Juli 2021 21:44
To: Greg KH <gregkh@linuxfoundation.org>; Schmid, Carsten <Carsten_Schmid@mentor.com>
Cc: USB list <linux-usb@vger.kernel.org>
Subject: Re: Possible race in 4.14 xhci stack

On 21.7.2021 11.14, Greg KH wrote:
> On Wed, Jul 21, 2021 at 07:51:58AM +0000, Schmid, Carsten wrote:
>> Hi Greg,
>>
>>>> Hi Mathias,
>>>>
>>>> i got a NULL pointer deref in the usbfs and analyzed it.
>>>> The connected device seemed to have trouble on USB transmissions.
>>>> However, I have the impression that there is a race between finishing URB handling and disconnection of devices.
>>>> In detail:
>>>> [ 4979.029666] xhci_hcd 0000:00:15.0: USB transfer error. Maybe the USB cable is bad?
>>>
>>> Did your cable die?
>>>
>>> And 4.14 is quite old, what about 5.13?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> That was reported from a device in the field.
>> Yes, a defective cable is bad, but shouldn't the kernel's health avoid a NULL pointer deref?
>
> Yes, I am not disagreeing about that, patches always welcome :)

Current kernel already has a cure for the symptom, avoiding the NULL pointer deref:

struct xhci_ring *xhci_triad_to_transfer_ring(...) {
struct xhci_virt_ep *ep;

ep = xhci_get_virt_ep(xhci, slot_id, ep_index);
if (!ep)
return NULL;
...
}

I'm still on vacation next week, but after that we could look closer at the root cause.

Thanks,
Mathias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955