Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

Hi,

On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote:
> Felipe Balbi <balbi@ti.com> writes:
> 
> >> > Because the fsl_udc_core driver shares one 'status_req' object for the
> >> > complete ep0 control transfer, it is not possible to prime the final
> >> > STATUS phase immediately after the IN transaction.  E.g. ch9getstatus()
> >> > executed:
> >> > 
> >> > | req = udc->status_req;
> >> > | ...
> >> > | list_add_tail(&req->queue, &ep->queue);
> >> > | if (ep0_prime_status(udc, EP_DIR_OUT))
> >> > |       ....
> >> > |       struct fsl_req *req = udc->status_req;
> >> > |       list_add_tail(&req->queue, &ep->queue);
> >> > 
> >> > which corrupts the ep->queue list by inserting 'status_req' twice.  This
> >> > causes a kernel oops e.g. when 'lsusb -v' is executed on the host.
> >> > 
> >> > Patch delays the final 'ep0_prime_status(udc, EP_DIR_OUT))' by moving it
> >> > into the ep0 completion handler.
> >> > 
> >> Enrico, thanks for pointing this problem.
> >> 
> >> As "prime STATUS phase immediately after the IN transaction" is followed
> >> USB 2.0 spec, to fix this problem, it is better to add data_req for ep0.
> >> In fact, it is already at FSL i.mx internal code, just still not mainlined.
> >
> > so, do I get an Acked-by to this patch ? Does it need to go on v3.6-rc
> > or can it wait until v3.7 merge window ?
> 
> Without this (or the mentioned data_req patch), I can crash a g_multi
> gadget by executing 'lsusb -v' as root on the host.  Should not be
> exploitable (only a BUG_ON() is triggered) but issue should be fixed
> asap.

cool, so I'll apply to my fixes branch as soon as I get Acked-by or
Tested-by from someone.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]