Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] usb: payload corruption due to oversized endpoint descriptor mapping --
commit 3644614322079b958f1f64d6f45046b653de97cb Author: Igor Skalkin <[email protected]> virtio-usb: add SuperSpeed device-role support This commit updates virtio-usb to dynamically parse the maximum supported speed from the host backend's bind event rather than hardcoding it. It also configures endpoint packet sizes accordingly and includes the companion descriptor alongside the endpoint descriptor for SuperSpeed bring-up. > diff --git a/drivers/usb/virtio_usb/device.c b/drivers/usb/virtio_usb/device.c > index 9ee1f050019f1..ee41ea9d164f1 100644 > --- a/drivers/usb/virtio_usb/device.c > +++ b/drivers/usb/virtio_usb/device.c [ ... ] > @@ -461,7 +463,13 @@ static void vep_enable_work(struct work_struct *work) > goto done; > } > > - sg_init_one(psg_data, desc, sizeof(*desc)); > + if (virtio_usb_ep_comp_valid(comp)) > + n_sgs = 2; > + > + sg_init_table(psg_data, n_sgs); > + sg_set_buf(&psg_data[0], desc, sizeof(*desc)); [Severity: High] Does mapping sizeof(*desc) misalign the payload sent to the host backend? Since sizeof(struct usb_endpoint_descriptor) is 9 bytes (which includes audio-only fields) and desc->bLength is typically 7, appending the companion descriptor immediately after this 9-byte chunk might shift it by 2 bytes in the resulting payload. When the host backend parses the descriptors sequentially by advancing bLength bytes, could this cause it to parse misaligned data instead of the companion descriptor, causing the SuperSpeed endpoint configuration to fail? > + if (n_sgs == 2) > + sg_set_buf(&psg_data[1], comp, sizeof(*comp)); > hdr = virtio_usb_cmd_request(cmd); > hdr->endpoint = cpu_to_le16(endpoint); > [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=7
