linux-kernel - Re: [RFC PATCH 1/1] usb: ehci: Remove erroneous return of EPROTO upon detection of stall

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: <20200904151920.GA3414684@kroah.com>
Date:   Fri, 4 Sep 2020 17:19:20 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Khalid Aziz <khalid.aziz@...cle.com>
Cc:     stern@...land.harvard.edu, erkka.talvitie@...cit.fi,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Khalid Aziz <khalid@...ehiking.org>
Subject: Re: [RFC PATCH 1/1] usb: ehci: Remove erroneous return of EPROTO
 upon detection of stall

On Mon, Aug 31, 2020 at 10:08:43AM -0600, Khalid Aziz wrote:
> With the USB 3.0/3.1 controller on MSI B450-A Pro Max motherboard,
> full speed and low speed devices see constant resets making
> keyboards and mouse unreliable and unusable. These resets are caused
> by detection of stall in qtd_copy_status() and returning EPROTO
> which in turn results in TT buffers in hub being cleared. Hubs do
> not seem to repsond well to this and seem to hang which causes
> further USB transactions to time out. A reset finally clears the
> issue until we repeat the cycle all over again.
> 
> Signed-off-by: Khalid Aziz <khalid.aziz@...cle.com>
> Cc: Khalid Aziz <khalid@...ehiking.org>
> ---
>  drivers/usb/host/ehci-q.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index 8a5c9b3ebe1e..7d4b2bc4633c 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -214,10 +214,6 @@ static int qtd_copy_status (
>  		 * When MMF is active and PID Code is IN, queue is halted.
>  		 * EHCI Specification, Table 4-13.
>  		 */
> -		} else if ((token & QTD_STS_MMF) &&
> -					(QTD_PID(token) == PID_CODE_IN)) {
> -			status = -EPROTO;
> -		/* CERR nonzero + halt --> stall */
>  		} else if (QTD_CERR(token)) {
>  			status = -EPIPE;
>  

Removing this check is not a good idea, any chance you can come up with
some other test instead for this broken hardware?

What about getting a USB hub that works?  :)

thanks,

greg k-h