On Fri, 2 Aug 2013, Sean O. Stalley wrote: > rh_call_control() contains a buffer, tbuf, which it uses to hold > USB descriptors. These discriptors are eventually copied into the > transfer_buffer in the URB. The buffer in the URB is dynamically > defined and is always large enough to hold the amount of data it > requests. > > tbuf, however, is statically allocated on the stack with a size > of 15 bytes, regardless of the size specified in the URB. > When this buffer is passed to the hcd via the hub_control() call, > it is advertized as being as large as the URB buffer ( via > wLength ). > > when the hcd attempts to write a descriptor containing more than > 15 bytes ( such as the Standard BOS Descriptor for hubs, defined > in the USB3.0 Spec, section 10.13.1 ) causes tbuf to overflow > onto the stack. No it doesn't. The usb_bos_descriptor data defined in xhci-hub.c is 15 bytes long. As far as I know, none of the descriptors written by the HCDs are longer than that. > This patchset includes 2 independant options, it is not > necessary to apply both. Option 1 simply increases the size > of tbuf, so that it can hold larger descriptors. Option 2 > circumvents tbuf and passes nongeneric descriptors (such as BOS > descriptors) directly to the buffer in the urb, preventing the > overflow. Neither patch is acceptable. Increasing tbuf to 4096 bytes uses far too much stack space. Passing data directly to the URB's buffer won't work, because that buffer may be smaller than the amount of data copied by the HCD. > A third option would be to rewrite the rh_call function. If you want the code to be a little less fragile than it is now, you could increase tbuf to 64 bytes, or something like that. However, at the moment I don't see why any change is needed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
