linux-kernel - Re: [PATCH v2 01/18] usb: vhci-hcd: Prevent suspending virtually attached devices

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: <2025072637-google-referable-dc99@gregkh>
Date: Sat, 26 Jul 2025 09:06:13 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
Cc: Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah@...nel.org>, Hongren Zheng <i@...ithal.me>,
	"Brian G. Merrell" <bgmerrell@...ell.com>, kernel@...labora.com,
	Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 01/18] usb: vhci-hcd: Prevent suspending virtually
 attached devices

On Sat, Jul 26, 2025 at 01:08:03AM +0300, Cristian Ciocaltea wrote:
> The VHCI platform driver aims to forbid entering system suspend when at
> least one of the virtual USB ports are bound to an active USB/IP
> connection.
> 
> However, in some cases, the detection logic doesn't work reliably, i.e.
> when all devices attached to the virtual root hub have been already
> suspended, leading to a broken suspend state, with unrecoverable resume.
> 
> Ensure the virtually attached devices do not enter suspend by setting
> the syscore PM flag.  Note this is currently limited to the client side
> only, since the server side doesn't implement system suspend prevention.
> 
> Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
> ---
>  drivers/usb/usbip/vhci_hcd.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index e70fba9f55d6a0edf3c5fde56a614dd3799406a1..b4b0ed5d64966214636b157968478600e2e4178a 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -765,6 +765,17 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag
>  				 ctrlreq->wValue, vdev->rhport);
>  
>  			vdev->udev = usb_get_dev(urb->dev);
> +			/*
> +			 * FIXME: A similar operation has been done via
> +			 * USB_REQ_GET_DESCRIPTOR handler below, which is
> +			 * supposed to always precede USB_REQ_SET_ADDRESS.

When is this FIXME going to be addressed and by whom?

> +			 *
> +			 * It's not entirely clear if operating on a different
> +			 * usb_device instance here is a real possibility,
> +			 * otherwise this call and vdev->udev assignment above
> +			 * should be dropped.

What is going to need to happen to figure this out?

thanks,

greg k-h