Hi,
On Tue, Nov 12, 2013 at 01:04:46PM -0800, David Cohen wrote:
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 5452c0fce360..7c2d36f6ad4b 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1130,6 +1130,14 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
> dev_vdbg(dwc->dev, "queing request %p to %s length %d\n",
> request, ep->name, request->length);
>
> + /* If ep out, roundup request->length to epout maxpacketsize */
> + if (!(dep->number & 1)) {
we have a direction field in the dep structure, please use that.
> + unsigned int aligned = roundup(request->length,
> + ep->desc->wMaxPacketSize);
> + req->pad = aligned - request->length;
> + request->length = aligned;
this is quite dangerous. You really don't know the size that gadget
driver allocated. What if we're using SLOB and gadget driver allocated
exactly 31 bytes (think MSC's CBW) ? Then you change request->length to
512-bytes (or 1024 if USB SS), and host happens to be buggy (or
exploited somehow) and sends more than 31-bytes ? You told dwc3 you
could receive more than 31-bytes even though you don't know what follows
your 31-byte buffer.
This is why I have been saying that gadget driver *must* be the one
hadnling this issue based on the quirk flag.
--
balbi
Attachment:
signature.asc
Description: Digital signature
