LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
To: balbi@ti.com
Cc: Chen Peter-B29397 <B29397@freescale.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Li Yang-R58472 <r58472@freescale.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer
Date: Thu, 06 Sep 2012 16:27:12 +0200	[thread overview]
Message-ID: <lyehmf1b27.fsf@ensc-virt.intern.sigma-chemnitz.de> (raw)
In-Reply-To: <20120906131708.GJ29202@arwen.pp.htv.fi> (Felipe Balbi's message of "Thu, 6 Sep 2012 16:17:10 +0300")

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.


Enrico

  reply	other threads:[~2012-09-06 14:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04 16:58 [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer Enrico Scholz
2012-09-05  2:10 ` Chen Peter-B29397
2012-09-06 13:17   ` Felipe Balbi
2012-09-06 14:27     ` Enrico Scholz [this message]
2012-09-06 14:27       ` Felipe Balbi
2012-09-10 16:22         ` Felipe Balbi
2012-09-12 11:17         ` Li Yang-R58472

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=lyehmf1b27.fsf@ensc-virt.intern.sigma-chemnitz.de \
    --to=enrico.scholz@sigma-chemnitz.de \
    --cc=B29397@freescale.com \
    --cc=balbi@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=r58472@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox