[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c4a8bd46-0ee4-4bc3-a572-824cb8a7e524@linux.intel.com>
Date: Fri, 7 Nov 2025 18:05:15 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Uttkarsh Aggarwal <uttkarsh.aggarwal@....qualcomm.com>,
Mathias Nyman <mathias.nyman@...el.com>, Greg KH <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
wesley.cheng@....qualcomm.com
Subject: Re: [RFT PATCH v3] xhci: sideband: Fix race condition in sideband
unregister
On 11/7/25 08:16, Uttkarsh Aggarwal wrote:
>
>
> On 10/29/2025 7:22 PM, Mathias Nyman wrote:
>> On 10/29/25 14:51, Greg KH wrote:
>>> On Wed, Oct 29, 2025 at 02:24:35PM +0200, Mathias Nyman wrote:
>>>> Uttkarsh Aggarwal observed a kernel panic during sideband un-register
>>>> and found it was caused by a race condition between sideband unregister,
>>>> and creating sideband interrupters.
>>>> The issue occurrs when thread T1 runs uaudio_disconnect() and released
>>>> sb->xhci via sideband_unregister, while thread T2 simultaneously accessed
>>>> the now-NULL sb->xhci in xhci_sideband_create_interrupter() resulting in
>>>> a crash.
>>>>
>>>> Ensure new endpoints or interrupter can't be added to a sidenband after
>>>> xhci_sideband_unregister() cleared the existing ones, and unlocked the
>>>> sideband mutex.
>>>> Reorganize code so that mutex is only taken and released once in
>>>> xhci_sideband_unregister(), and clear sb->vdev while mutex is taken.
>>>>
>>>> Use mutex guards to reduce human unlock errors in code
>>>>
>>>> Refuse to add endpoints or interrupter if sb->vdev is not set.
>>>> sb->vdev is set when sideband is created and registered.
>>>>
>>>> Reported-by: Uttkarsh Aggarwal <uttkarsh.aggarwal@....qualcomm.com>
>>>> Closes: https://lore.kernel.org/linux-usb/20251028080043.27760-1- uttkarsh.aggarwal@....qualcomm.com
>>>> Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
>>>> Signed-off-by: Mathias Nyman <mathias.nyman@...ux.intel.com>
>>>> ---
>>>
>>> Looks good, thanks for respinning this. I don't know if it fixes the
>>> issue, but it looks sane :)
>>>
>>> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>
>> Thanks for reviewing this.
>>
>> I don't have the hardware to test this myself either
>>
>> Thanks
>> Mathias
>
> Hi Mathias,
>
> I have shared the patch with our OEMs and so far, have not received any reports of issues from them.
>
> Thanks
> Uttkarsh
>
Thanks, I'll send it forward
-Mathias
Powered by blists - more mailing lists