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:st...@rowland.harvard.edu] 
Sent: Friday, August 09, 2013 7:17 AM
To: Stalley, Sean
Cc: linux-usb@vger.kernel.org; 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 <st...@rowland.harvard.edu>

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to