All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Raul E Rangel" <rrangel@chromium.org>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH 6/6] usbip: vhci_hcd: reject URBs from stale usb_device after port re-attach
Date: Wed, 21 Oct 2026 15:17:48 +0000	[thread overview]
Message-ID: <sashiko-outbox-180428@kernel.org> (raw)
In-Reply-To: <20261021150704.3129446-7-rrangel@chromium.org>

> After vhci_shutdown_connection() runs, event_handler() immediately
> calls vhci_device_reset(), setting vdev->ud.status to VDEV_ST_NULL and
> clearing vdev->udev before usb_hub_wq finishes running usb_disconnect()
> on the detached usb_device.
> 
> If attach_store() attaches a new connection to the same rhport before
> usb_hub_wq disconnects the old usb_device, vdev->ud.tcp_socket becomes
> non-NULL and vdev->ud.status becomes VDEV_ST_NOTASSIGNED. Because
> vhci_urb_enqueue() maps urb->dev->portnum to vdev without verifying that
> urb->dev matches vdev->udev, URBs submitted on the old usb_device pass
> the connection state checks and get sent to the new remote device (or,
> if a concurrent USBDEVFS_RESET resets the old usb_device to address 0,
> overwrite vdev->udev).
> 
> Serialize vdev->udev clearing in vhci_device_reset() under vhci->lock
> and ud->lock (dropping old usb_device and socket references outside the
> spinlocks in both vhci_device_reset() and vhci_urb_enqueue()), and
> reject URBs in vhci_urb_enqueue() when urb->dev != vdev->udev and either
> usb_pipedevice(urb->pipe) != 0 or urb->dev is already registered
> (device_is_registered(&urb->dev->dev)). During initial enumeration and
> PORT_INIT_TRIES retries in hub_port_connect(), each candidate usb_device
> is unregistered until usb_new_device() runs after hub_port_init() has
> assigned vdev->udev, whereas an already-registered usb_device resetting
> via usb_reset_device() is only valid when urb->dev == vdev->udev.
> 
> Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver")
> Cc: stable@vger.kernel.org
> Assisted-by: Gemini
> Signed-off-by: Raul E Rangel <rrangel@chromium.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021150704.3129446-1-rrangel@chromium.org?part=6


      reply	other threads:[~2026-10-21 15:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 15:06 [PATCH 0/6] usbip: vhci_hcd: fix URB giveback leaks and disconnect races Raul E Rangel
2026-10-21 15:06 ` [PATCH 1/6] usbip: vhci_hcd: protect urb->hcpriv with priv_lock in vhci_urb_dequeue() Raul E Rangel
2026-10-21 15:13   ` sashiko-bot
2026-10-21 15:06 ` [PATCH 2/6] usbip: vhci_hcd: complete unsent URBs locally " Raul E Rangel
2026-10-21 15:14   ` sashiko-bot
2026-10-21 15:06 ` [PATCH 3/6] usbip: vhci_hcd: stop enqueue and drain all pending URBs on disconnect Raul E Rangel
2026-10-21 15:22   ` sashiko-bot
2026-10-21 15:06 ` [PATCH 4/6] usbip: vhci_hcd: clear URB_DMA_MAP_SG on all giveback paths Raul E Rangel
2026-10-21 15:14   ` sashiko-bot
2026-10-21 15:07 ` [PATCH 5/6] usbip: vhci_hcd: allocate vhci_priv outside lock and handle ENOMEM Raul E Rangel
2026-10-21 15:16   ` sashiko-bot
2026-10-21 15:07 ` [PATCH 6/6] usbip: vhci_hcd: reject URBs from stale usb_device after port re-attach Raul E Rangel
2026-10-21 15:17   ` sashiko-bot [this message]

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=sashiko-outbox-180428@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rrangel@chromium.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.