linux-kernel - Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1702281327230.2075-100000@iolanthe.rowland.org>
Date:   Tue, 28 Feb 2017 13:34:05 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Felipe Balbi <balbi@...nel.org>
cc:     Baolin Wang <baolin.wang@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for
 handling delay STATUS phase

On Tue, 28 Feb 2017, Felipe Balbi wrote:

> 
> Hi,
> 
> Alan Stern <stern@...land.harvard.edu> writes:
> >> So I am not sure how the Gadget driver can figure out that it needs to
> >> usb_ep_queue() another request for status stage when handling the
> >> no-data control?
> >
> > Gadget drivers already queue status-stage requests for no-data
> > control-OUT requests.  The difficulty comes when you want to handle an
> > IN request or an OUT request with a data stage.
> 
> I don't see a difficulty there. Gadget driver will see wLength and
> notice it needs both data and status stages, then it does:
> 
> usb_ep_queue(ep0, data_req, GFP_KERNEL);
> usb_ep_queue(ep0, status_req, GFP_KERNEL);

The main difficulty is that all the gadget/function drivers will have 
to be audited to add the status requests.

> Just needs to prepare both requests and queue them both ahead of
> time. UDC drivers should hold both requests in their own private list
> and process one at a time.

Or the gadget driver should queue the status request after the 
data stage has been fully processed, in the case of an OUT transfer.

There is still a possible race.  The host might send another SETUP
packet before the status request has been queued, or after it has been
queued but before the UDC driver has completed it.  (Of course, that's 
already true now for the data request...)

Alan Stern