From: sashiko-bot@kernel.org
To: "YuanZhe Liu" <25031212351@stu.xidian.edu.cn>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v5] usb: usbfs: Require claiming a hub interface for hub class requests
Date: Fri, 06 Nov 2026 09:32:56 +0000 [thread overview]
Message-ID: <sashiko-outbox-201113@kernel.org> (raw)
In-Reply-To: <20261106091048.4056-1-25031212351@stu.xidian.edu.cn>
> check_ctrlrecip() requires the matching interface to be claimed for
> requests addressed to an interface or an endpoint, but requests
> addressed to the device or to a port are passed through without any
> check. For a hub that means userspace can send hub class requests
> through usbfs without claiming the hub interface, while the hub driver
> owns the ports. Port requests use USB_RT_PORT, whose recipient is
> USB_RECIP_OTHER, and SetPortFeature(PORT_SUSPEND) is one of them.
>
> That is more than a policy question. The request goes to the HCD, and
> it can run concurrently with userspace releasing the hub interface
> through USBDEVFS_DISCONNECT_CLAIM, which unbinds the hub driver and
> disconnects the devices behind it. xhci_hcd tracks the device behind
> each port and issues stop endpoint commands for it in its port suspend
> path, and it ended up reading a freed xhci_virt_device.
>
> Require interface 0 to be claimed for every non-GET request to a hub.
> The hub driver matches devices by device class or by interface class,
> but a hub has a single interface either way, and that is the one the
> driver holds.
>
> Userspace can no longer change port settings while the hub driver is
> bound. USBDEVFS_CLAIM_PORT hands over the device behind a port, not the
> port itself, so a request that pokes port state is not safe for a
> claimed port either. Programs that used to do this have to unbind the
> hub driver first.
>
> Signed-off-by: YuanZhe Liu <25031212351@stu.xidian.edu.cn>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106091048.4056-1-25031212351@stu.xidian.edu.cn?part=1
next prev parent reply other threads:[~2026-11-06 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261105054333.7811-25031212351@stu.xidian.edu.cn>
2026-11-05 6:56 ` [PATCH v3] usb: usbfs: Require claiming a hub interface for hub class requests YuanZhe Liu
2026-11-05 7:14 ` sashiko-bot
2026-11-05 17:11 ` Alan Stern
2026-11-05 18:55 ` Michal Pecio
2026-11-05 17:23 ` [PATCH v4] " YuanZhe Liu
2026-11-05 17:41 ` sashiko-bot
2026-11-05 17:44 ` Alan Stern
2026-11-06 9:10 ` [PATCH v5] " YuanZhe Liu
2026-11-06 9:32 ` sashiko-bot [this message]
2026-11-06 9:50 ` Michal Pecio
2026-11-11 4:27 ` YuanZhe Liu
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-201113@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=25031212351@stu.xidian.edu.cn \
--cc=linux-usb@vger.kernel.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.