On Friday 21 January 2005 10:22 am, Alan Stern wrote: > > I've been looking through hcd.c:rh_call_control(), intending to fix a > single problem (it alters urb->status without locking urb->lock). It > turns out there are a couple of other problems there too. > > 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? > 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. 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. > Do you agree that these things need to be fixed? The latter, yes. Unlikely to make trouble, since usbcore always passes big-enough buffers and all heap buffers are big enough; but worth fixing. - Dave ------------------------------------------------------- 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
