From: Greg KH <gregkh@linuxfoundation.org>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: uttkarsh.aggarwal@oss.qualcomm.com, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, mathias.nyman@intel.com,
wesley.cheng@oss.qualcomm.com
Subject: Re: [RFT PATCH v3] xhci: sideband: Fix race condition in sideband unregister
Date: Wed, 29 Oct 2025 13:51:19 +0100 [thread overview]
Message-ID: <2025102956-daunting-roping-a987@gregkh> (raw)
In-Reply-To: <20251029122436.375009-1-mathias.nyman@linux.intel.com>
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@oss.qualcomm.com>
> Closes: https://lore.kernel.org/linux-usb/20251028080043.27760-1-uttkarsh.aggarwal@oss.qualcomm.com
> Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.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@linuxfoundation.org>
next prev parent reply other threads:[~2025-10-29 12:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 8:00 [PATCH] xhci: sideband: Fix race condition in sideband unregister Uttkarsh Aggarwal
2025-10-28 8:45 ` Greg Kroah-Hartman
2025-10-28 12:15 ` Mathias Nyman
2025-10-28 13:44 ` [RFT PATCH] " Mathias Nyman
2025-10-28 13:56 ` Greg KH
2025-10-28 14:59 ` Mathias Nyman
2025-10-28 16:51 ` [RFT PATCH v2] " Mathias Nyman
2025-10-29 10:14 ` Greg KH
2025-10-29 12:24 ` [RFT PATCH v3] " Mathias Nyman
2025-10-29 12:51 ` Greg KH [this message]
2025-10-29 13:52 ` Mathias Nyman
2025-11-07 6:16 ` Uttkarsh Aggarwal
2025-11-07 16:05 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025102956-daunting-roping-a987@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=uttkarsh.aggarwal@oss.qualcomm.com \
--cc=wesley.cheng@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.