linux-kernel - Re: dwc3: unusual handling of setup requests with wLength == 0

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: <CA+fCnZdewxqN6jaOmah4Ptz5CaJoc6iKisFBMLujBGOD_6HoiA@mail.gmail.com>
Date:   Fri, 25 Aug 2023 03:36:36 +0200
From:   Andrey Konovalov <andreyknvl@...il.com>
To:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Alan Stern <stern@...land.harvard.edu>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: dwc3: unusual handling of setup requests with wLength == 0

On Wed, Aug 23, 2023 at 7:18 PM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
>
> > > First, I noticed that some of the UDC drivers only expect to handle a
> > > delayed Status stage for SET_CONFIGURATION requests. (Which is
>
> Just want to clarify that dwc3 would expect a delayed status for any
> request returned with USB_GADGET_DELAYED_STATUS. The issue is that dwc3
> assumes the _first_ delayed request would be SET_CONFIGURATION. Any
> subsequence control request with delayed request, it assumes the device
> is already in configured state.
>
> > That expectation is wrong; gadget drivers can also want to delay the
> > Status stage for a SET_INTERFACE request.  And in theory they might want
> > to delay any control-OUT transfer.
>
> Agree. Thanks Andrey and Alan for looking into dwc3.
>
> Regarding SET_INTERFACE, it should be fine because it should be done
> while it's already in configured state, which is after
> SET_CONFIGURATION. But it's true that dwc3 needs to fix this assumption
> here.

Ack.

Thank you Thinh and Alan for taking the time to look into this!

So to summarize the issue wrt the 0-length requests:

1. UDC drivers must always delay the status stage for 0-length
requests until the gadget driver queues an empty request.

2. Many UDC drivers do not do this, and only delay the status stage
when USB_GADGET_DELAYED_STATUS is returned from ->setup(). Some
drivers also assume that only a SET_CONFIGURATION request can be
delayed.

3. All such UDC drivers should be fixed and USB_GADGET_DELAYED_STATUS
should be contained within the composite framework.

4. Fixing all such UDC drivers is a non-trivial amount of work, but
this is the goal to strive towards.

Alan, would it be acceptable if I add custom handling of
USB_GADGET_DELAYED_STATUS to Raw Gadget in the meantime? It would be
great to keep it at least somewhat working with dwc3. I can also do it
for GadgetFS, if you think it's a good idea.

I can also add some clarifying comments for USB_GADGET_DELAYED_STATUS
and ->setup() to hopefully avoid having new UDC drivers being added
with the same issue (e.g. cdns2 and renesas_usbf with the same issue
were added just recently).

Maybe it's also a good idea to add a checkpatch.pl check for using
USB_GADGET_DELAYED_STATUS in UDC drivers. Or maybe ask Greg to keep an
eye out for this?