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: <YzRofTAx+3pPCbrL@rowland.harvard.edu>
Date:   Wed, 28 Sep 2022 11:30:05 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Chunfeng Yun <chunfeng.yun@...iatek.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-usb@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Eddie Hung <eddie.hung@...iatek.com>,
        Min Guo <min.guo@...iatek.com>,
        Tianping Fang <tianping.fang@...iatek.com>,
        Stable@...r.kernel.org
Subject: Re: [PATCH 1/2] usb: mtu3: fix ep0's stall of out data stage

On Wed, Sep 28, 2022 at 05:17:20PM +0800, Chunfeng Yun wrote:
> It happens when enable uvc function, the flow as below:
> the controller switch to data stage, then call
>     -> foward_to_driver() -> composite_setup() -> uvc_function_setup(),
> it send out an event to user layer to notify it call
>     -> ioctl() -> uvc_send_response() -> usb_ep_queue(),
> but before the user call ioctl to queue ep0's buffer, the host already send
> out data, but the controller find that no buffer is queued to receive data,
> it send out STALL handshake.
> 
> To fix the issue, don't send out ACK of setup stage to switch to out data
> stage until the buffer is available.

You might find it is better to use the delayed_status routines already 
present in the Gadget core.  Instead of delaying the response to the 
Setup packet of the second control transfer, delay the status response 
to the first control transfer.

This approach has the advantage of working even when the second transfer 
is not control but something else, such as bulk.

Also it agrees better with the way the USB spec intends control 
transfers to work.  The UDC is not supposed to complete the status stage 
of a control transfer until the gadget has fully processed the 
transfer's information and is ready to go forward.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ