Alan, Just wondering why we don't require the HCDs to validate the length instead of blindly copying the descriptor to the buffer passed in. In the pseudo host controller we are developing we only copy the number of bytes requested to the buffer passed in. Thx! Rahman -----Original Message----- From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] Sent: Friday, August 09, 2013 7:17 AM To: Stalley, Sean Cc: linux-usb@xxxxxxxxxxxxxxx; Sarah Sharp; Ismail, Abdul R Subject: Re: [RFC V3] usb: rh_call_control tbuf overflow fix On Thu, 8 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 is currently statically allocated on the stack with a size of 15 > bytes, regardless of the size specified in the URB. > This patch dynamically allocates tbuf, and ensures that tbuf is at > least as big as the buffer in the URB. > > If an 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 ) the write would overflow the buffer > and corrupt the stack. This patch addresses this behavior. This version is better. You can add: Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> However, it doesn't really solve the original problem. Let's say a new sort of descriptor is added, something longer than 16 bytes. Suppose somebody submits an URB to read just the first 2 bytes of this descriptor, so wLength is 2. What will happen then? 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
