On Fri, Aug 09, 2013 at 08:51:30AM -0700, Sarah Sharp wrote:
> On Thu, Aug 08, 2013 at 04:11:46PM -0700, Greg KH wrote:
> > Note, I don't apply "RFC" patches, and rarely review them. Why are you
> > claiming that is what this is, when it is in the 3rd version already?
>
> This is a new approach f
On Fri, 9 Aug 2013, Ismail, Abdul R wrote:
> 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 buf
ssage-
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
On Thu, Aug 08, 2013 at 04:11:46PM -0700, Greg KH wrote:
> Note, I don't apply "RFC" patches, and rarely review them. Why are you
> claiming that is what this is, when it is in the 3rd version already?
This is a new approach from the last patch (dynamic allocation vs.
making the static tbuf bigge
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 amou
August 08, 2013 4:12 PM
> 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
>
> Note, I don't apply "RFC" patches, and rarely review them. Why are you
> claiming that is w
Note, I don't apply "RFC" patches, and rarely review them. Why are you
claiming that is what this is, when it is in the 3rd version already?
greg k-h
--
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 a