On Friday 21 January 2005 11:51 am, Alan Stern wrote:
> On Fri, 21 Jan 2005, David Brownell wrote:
> 
> > > In particular, the routine isn't careful about not copying more than
> > > wLength bytes for small transfers.  
> > 
> > It's careful about not writing more than urb->transfer_buffer_length
> > though, and insists wLength not exceed that... how then could that
> > routine copy more than wLength?
> 
> One example will demonstrate the point.  Look at what happens when typeReq 
> == (DeviceRequest | USB_REQ_GET_STATUS) (that's the first case in the 
> big switch statement) and wLength == 0 or 1.

OK.  Now, who would do such a silly thing?  :)

The fix discussed below could address this, too.


> > > And when handling class requests 
> > > there's no way for the HCD's hub_control() routine to set the proper value
> > > in urb->actual_length.  (The hub_control routines aren't careful not to
> > > copy more than wLength bytes either.)
> > 
> > Hmm, I remember thinking they wouldn't need to do that because they'd
> > always be copying into a temporary buffer, but I see that's not how
> > they work.  In this case, it's much better to keep all error checking
> > out of the HCDs.
> 
> Agreed.
> 
> > If the temporary buffer in rh_call_control() were big enough to hold a
> > usb_hub_descriptor there'd be no problem, since that's bigger than either
> > hub or port status (both are LE32), and those are the only values returned
> > by HCDs.  Just set "bufp" to that before calling the HCD.
> 
> Okay, I'll do that.  How do you suggest getting the actual_length value 
> back from the HCD?  Interpret non-negative status return as actual_length?
> Add an additional pointer-to-int argument to hub_control?  Either way, the 
> HCDs will have to be changed.

Nah, just keep it simple.  The HCD (and that switch statement) should
be able to rely on a big-enough scratch buffer in all cases.  Then make
all IN transfers memcpy() the right amount from that buffer ... no changes
needed to the HCDs.

- Dave


> 
> Alan Stern
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to