linux-kernel - Re: [PATCH v2] vhci_hcd: USB port can get stuck in the disabled state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7b02cb66-d672-ae95-01ea-c6015725e1ac@linuxfoundation.org>
Date:   Wed, 21 Jul 2021 19:26:02 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Michael Broadfoot <msbroadf@...il.com>,
        valentina.manea.m@...il.com, shuah@...nel.org,
        gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2] vhci_hcd: USB port can get stuck in the disabled state

On 7/21/21 5:55 PM, Michael Broadfoot wrote:
> When a remote usb device is attached to the local Virtual USB
> Host Controller Root Hub port, the bound device driver may send a
> port reset command. For example to initialize firmware (eg. btusb does this).
> This port reset command can be sent at any time, however the VHCI hcd
> root hub is only expecting reset to occur before the device receives
> SET_ADDRESS. The USB port should always be enabled after a reset
> (because the port is virtual and there is no possibility of hardware errors)
> 
> 
> 
> Signed-off-by: Michael Broadfoot <msbroadf@...il.com>
> ---
>   drivers/usb/usbip/vhci_hcd.c | 13 ++++---------
>   1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 4ba6bcdaa8e9..d3cda1b2c15a 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -455,15 +455,10 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>   			vhci_hcd->port_status[rhport] &= ~(1 << USB_PORT_FEAT_RESET);
>   			vhci_hcd->re_timeout = 0;
>   
> -			if (vhci_hcd->vdev[rhport].ud.status ==
> -			    VDEV_ST_NOTASSIGNED) {
> -				usbip_dbg_vhci_rh(
> -					" enable rhport %d (status %u)\n",
> -					rhport,
> -					vhci_hcd->vdev[rhport].ud.status);
> -				vhci_hcd->port_status[rhport] |=
> -					USB_PORT_STAT_ENABLE;
> -			}

VDEV_ST_NOTASSIGNED status indicates that the vdev is in use without
address assigned - in other words port is initializing.

This is part of the attach request handling when user requests to
attach to a remote device. attach_store() will change the status
to VDEV_ST_NOTASSIGNED and then initiate port_connect sequence.

We don't want to touch the vdev when it is in other states.
   
> +			usbip_dbg_vhci_rh(" enable rhport %d (status %u)\n",
> +					  rhport,
> +					  vhci_hcd->vdev[rhport].ud.status);
> +			vhci_hcd->port_status[rhport] |= USB_PORT_STAT_ENABLE;
>   
>   			if (hcd->speed < HCD_USB3) {
>   				switch (vhci_hcd->vdev[rhport].speed) {
> 

How did you find this problem? Does the port get into stuck state
while attaching to a remote usbip device on the host?

thanks,
-- Shuah