Hi, On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote: > Felipe Balbi <ba...@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
signature.asc
Description: Digital signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
