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
next prev parent 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