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] xhci: sideband: Fix race condition in sideband unregister
Date: Tue, 28 Oct 2025 14:56:42 +0100 [thread overview]
Message-ID: <2025102808-sublime-substance-74bb@gregkh> (raw)
In-Reply-To: <20251028134452.244096-1-mathias.nyman@linux.intel.com>
On Tue, Oct 28, 2025 at 03:44:51PM +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.
> Reorganise code so that mutex is only taken and released once in
> xhci_sideband_unregister(), and clear sb->vdev while mutex is taken.
>
> 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>
> ---
> drivers/usb/host/xhci-sideband.c | 55 ++++++++++++++++++++++++--------
> 1 file changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> index e771a476fef2..c308be9a8e9f 100644
> --- a/drivers/usb/host/xhci-sideband.c
> +++ b/drivers/usb/host/xhci-sideband.c
> @@ -86,6 +86,22 @@ __xhci_sideband_remove_endpoint(struct xhci_sideband *sb, struct xhci_virt_ep *e
> sb->eps[ep->ep_index] = NULL;
> }
>
> +static void
> +__xhci_sideband_remove_interrupter(struct xhci_sideband *sb)
> +{
> + struct usb_device *udev;
> +
> + if (!sb->ir)
> + return;
> +
> + xhci_remove_secondary_interrupter(xhci_to_hcd(sb->xhci), sb->ir);
> + sb->ir = NULL;
> + udev = sb->vdev->udev;
> +
> + if (udev->state != USB_STATE_NOTATTACHED)
> + usb_offload_put(udev);
> +}
> +
> /* sideband api functions */
>
> /**
> @@ -132,6 +148,12 @@ xhci_sideband_add_endpoint(struct xhci_sideband *sb,
> unsigned int ep_index;
>
> mutex_lock(&sb->mutex);
> +
> + if (!sb->vdev) {
> + mutex_unlock(&sb->mutex);
> + return -ENODEV;
> + }
> +
> ep_index = xhci_get_endpoint_index(&host_ep->desc);
> ep = &sb->vdev->eps[ep_index];
>
> @@ -317,6 +339,12 @@ xhci_sideband_create_interrupter(struct xhci_sideband *sb, int num_seg,
> return -ENODEV;
>
> mutex_lock(&sb->mutex);
> +
> + if (!sb->vdev) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> if (sb->ir) {
> ret = -EBUSY;
> goto out;
> @@ -352,20 +380,11 @@ EXPORT_SYMBOL_GPL(xhci_sideband_create_interrupter);
> void
> xhci_sideband_remove_interrupter(struct xhci_sideband *sb)
> {
> - struct usb_device *udev;
> -
> - if (!sb || !sb->ir)
> + if (!sb)
> return;
>
> mutex_lock(&sb->mutex);
> - xhci_remove_secondary_interrupter(xhci_to_hcd(sb->xhci), sb->ir);
> -
> - sb->ir = NULL;
> - udev = sb->vdev->udev;
> -
> - if (udev->state != USB_STATE_NOTATTACHED)
> - usb_offload_put(udev);
> -
> + __xhci_sideband_remove_interrupter(sb);
> mutex_unlock(&sb->mutex);
> }
> EXPORT_SYMBOL_GPL(xhci_sideband_remove_interrupter);
> @@ -465,6 +484,7 @@ EXPORT_SYMBOL_GPL(xhci_sideband_register);
> void
> xhci_sideband_unregister(struct xhci_sideband *sb)
> {
> + struct xhci_virt_device *vdev;
> struct xhci_hcd *xhci;
> int i;
>
> @@ -474,16 +494,23 @@ xhci_sideband_unregister(struct xhci_sideband *sb)
> xhci = sb->xhci;
>
> mutex_lock(&sb->mutex);
> +
> + vdev = sb->vdev;
> + if (!vdev)
> + return;
Lock is still held :(
I think you need to use guard() to make this more sane.
thanks,
greg k-h
next prev parent reply other threads:[~2025-10-28 13:56 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 [this message]
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
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=2025102808-sublime-substance-74bb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox