Linux virtualization list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Igor Skalkin" <igor.skalkin@oss.qualcomm.com>
Cc: virtualization@lists.linux.dev,
	"Eugenio Perez" <eperezma@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH 8/8] virtio-usb: support a guest UDC name prefix from the bind event
Date: Thu, 24 Sep 2026 16:35:35 +0000	[thread overview]
Message-ID: <20260924163535.7BAB21F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924160907.145405-9-igor.skalkin@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] usb: virtio_usb: missing sanitization of host-provided UDC name
- [Low] usb: virtio_usb: stale parent device name retained on BIND retry
--

commit b4fd3e9cac2d1567822e6a554abe7a7e1afb42b9
Author: Igor Skalkin <igor.skalkin@oss.qualcomm.com>

virtio-usb: support a guest UDC name prefix from the bind event

This commit allows the host backend to supply a name prefix for a port's UDC
parent platform_device via the bind event. If the prefix is present, it is
used as the parent device's name and to construct the gadget name; otherwise,
it falls back to the generic GADGET_NAME.

> diff --git a/drivers/usb/virtio_usb/device.c b/drivers/usb/virtio_usb/device.c
> index ee41ea9d164f1..fedce742f9781 100644
> --- a/drivers/usb/virtio_usb/device.c
> +++ b/drivers/usb/virtio_usb/device.c
> @@ -1369,11 +1369,26 @@ static int virtio_usb_dc_get_endpoint_info(struct virtio_usb_dc *vudc)
>  	return rc;
>  }
>  
> -static int virtio_usb_dc_parent_create(struct virtio_usb_dc *vudc)
> +static int virtio_usb_dc_parent_create(struct virtio_usb_dc *vudc,
> +				       const unsigned char *udc_prefix)
>  {
> +	size_t prefix_len;
> +	char *parent_name;
>  	int rc;
>  
> -	vudc->pdev = platform_device_alloc(GADGET_NAME, vudc->port);
> +	prefix_len = strnlen((const char *)udc_prefix,
> +			     VIRTIO_USB_UDC_NAME_PREFIX_MAX);
> +	if (prefix_len) {
> +		parent_name = kasprintf(GFP_KERNEL, "%.*s", (int)prefix_len,
> +					(const char *)udc_prefix);

[Severity: High]
Does this code adequately sanitize the host-provided udc_prefix string?

If a malicious host supplies a string with invalid characters (such as '/'),
passing this unsanitized string directly into kasprintf to construct the parent
platform device name could trigger a kernel WARN in kobject_add(), which would
panic the guest if panic_on_warn is enabled.

> +	} else {
> +		parent_name = kstrdup(GADGET_NAME, GFP_KERNEL);
> +	}
> +	if (!parent_name)
> +		return -ENOMEM;
> +
> +	vudc->pdev = platform_device_alloc(parent_name, vudc->port);
> +	kfree(parent_name);
>  	if (!vudc->pdev)
>  		return -ENOMEM;

[ ... ]

> @@ -1447,7 +1463,8 @@ static void virtio_usb_dc_event_process(struct virtio_usb_event *event)
>  			break;
>  		}
>  		if (!vudc->pdev) {
> -			rc = virtio_usb_dc_parent_create(vudc);
> +			rc = virtio_usb_dc_parent_create(
> +				vudc, bind_evt->udc_name_prefix);

[Severity: Low]
If a previous BIND event failed later in this function, could vudc->pdev still
be populated here?

If it was left populated by a prior failed BIND, the new prefix is ignored,
and the parent platform device will retain a stale name from the previous BIND
event.

>  			if (rc) {
>  				dev_err(&vusb->vdev->dev,
>  					"Failed to create UDC parent device\n");
> @@ -1456,8 +1473,18 @@ static void virtio_usb_dc_event_process(struct virtio_usb_event *event)
>  				break;
>  			}
>  		}
> -		vudc->gadget.name =
> -			kasprintf(GFP_KERNEL, "%s_%d", GADGET_NAME, port_id);
> +		udc_prefix_len =
> +			strnlen((const char *)bind_evt->udc_name_prefix,
> +				VIRTIO_USB_UDC_NAME_PREFIX_MAX);
> +		if (udc_prefix_len) {
> +			vudc->gadget.name = kasprintf(
> +				GFP_KERNEL, "%.*s_p%d", (int)udc_prefix_len,
> +				(const char *)bind_evt->udc_name_prefix,
> +				port_id);

[Severity: High]
Are there any missing sanitization checks on the host-provided
bind_evt->udc_name_prefix here?

This unsanitized string is used to build the gadget name, which will also be
passed to device registration APIs. Similar to the parent_name, a malicious
host supplying invalid characters can trigger a kernel WARN or panic.

> +		} else {
> +			vudc->gadget.name = kasprintf(GFP_KERNEL, "%s_%d",
> +						      GADGET_NAME, port_id);
> +		}
>  		if (!vudc->gadget.name) {
>  			rc = -ENOMEM;
>  			kfree(vudc->veps);
> @@ -1480,7 +1507,6 @@ static void virtio_usb_dc_event_process(struct virtio_usb_event *event)
>  			break;
>  		}
>  
> -		//vudc->gadget.dev.init_name = gadget_name;
>  		vudc->gadget.dev.parent = &vudc->pdev->dev;
>  		rc = usb_add_gadget_udc(&vudc->pdev->dev, &vudc->gadget);
>  		if (rc) {
>  			dev_err(&vudc->pdev->dev, "Failed to add udc\n");
>  			kfree(vudc->veps);
>  			vudc->veps = NULL;
>  			kfree(vudc->gadget.name);
>  			break;
>  		}

[Severity: Low]
Does this error path fail to unregister vudc->pdev?

By not unregistering vudc->pdev, it is left for the next BIND event to wrongly
reuse. This creates a mismatch between the parent device name and the new
gadget name in sysfs on a BIND retry.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924160907.145405-1-igor.skalkin@oss.qualcomm.com?part=8

  reply	other threads:[~2026-09-24 16:35 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 16:08 [PATCH 0/8] virtio-usb: add dual-role virtio USB driver Igor Skalkin
2026-09-24 16:09 ` [PATCH 1/8] virtio-usb: add protocol header and skeleton dual-role driver Igor Skalkin
2026-09-24 16:23   ` sashiko-bot
2026-09-25  5:14   ` Greg Kroah-Hartman
2026-09-28 14:19     ` Igor Skalkin
2026-09-25  5:21   ` Greg Kroah-Hartman
2026-09-28 14:14     ` Igor Skalkin
2026-09-24 16:09 ` [PATCH 2/8] virtio-usb: add host role (USB Host Controller) support Igor Skalkin
2026-09-24 16:25   ` sashiko-bot
2026-09-25  5:18   ` Greg Kroah-Hartman
2026-09-28 14:01     ` Igor Skalkin
2026-09-24 16:09 ` [PATCH 3/8] virtio-usb: add device role (USB Device " Igor Skalkin
2026-09-24 16:28   ` sashiko-bot
2026-09-24 16:09 ` [PATCH 4/8] virtio-usb: add OTG role query support Igor Skalkin
2026-09-24 16:19   ` sashiko-bot
2026-09-24 16:09 ` [PATCH 5/8] virtio-usb: add USB On-The-Go role-switching support Igor Skalkin
2026-09-24 16:24   ` sashiko-bot
2026-09-24 16:09 ` [PATCH 6/8] virtio-usb: rework endpoint lifecycle to an async split-phase state machine Igor Skalkin
2026-09-24 16:30   ` sashiko-bot
2026-09-24 16:09 ` [PATCH 7/8] virtio-usb: add SuperSpeed device-role support Igor Skalkin
2026-09-24 16:35   ` sashiko-bot
2026-09-24 16:09 ` [PATCH 8/8] virtio-usb: support a guest UDC name prefix from the bind event Igor Skalkin
2026-09-24 16:35   ` sashiko-bot [this message]
2026-09-25  5:17 ` [PATCH 0/8] virtio-usb: add dual-role virtio USB driver Greg Kroah-Hartman
2026-09-28 13:55   ` Igor Skalkin
2026-09-28 14:44     ` Greg Kroah-Hartman
2026-09-28 15:56       ` Igor Skalkin
2026-09-28 16:10         ` Greg Kroah-Hartman
2026-09-29  9:47     ` Michael S. Tsirkin
2026-09-29 16:01       ` Greg Kroah-Hartman
2026-09-29 19:02         ` Vasilii Ianikeev
2026-09-29 19:58         ` Vasilii Ianikeev

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=20260924163535.7BAB21F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=igor.skalkin@oss.qualcomm.com \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=virtualization@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox