linux-kernel - Re: [RFC RESEND PATCH 0/1] USB EHCI: repeated resets on full and low speed devices

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200901161848.GF587030@rowland.harvard.edu>
Date:   Tue, 1 Sep 2020 12:18:48 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Khalid Aziz <khalid.aziz@...cle.com>
Cc:     gregkh@...uxfoundation.org, erkka.talvitie@...cit.fi,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC RESEND PATCH 0/1] USB EHCI: repeated resets on full and low
 speed devices

On Tue, Sep 01, 2020 at 08:51:14AM -0700, Khalid Aziz wrote:
> >> At the time of failure, when we reach this conditional, token is
> >> either 0x80408d46 or 0x408d46 which means following bits are set:
> >>
> >> QTD_STS_STS, QTD_STS_MMF, QTD_STS_HALT, QTD_IOC, QTD_TOGGLE
> >>
> >> and 
> >>
> >>         QTD_PID = 1
> >>         QTD_CERR = 3
> >>         QTD_LENGTH = 0x40 (64)
> >>
> >> This causes  the branch "(token & QTD_STS_MMF) && (QTD_PID(token) ==
> >> PID_CODE_IN" to be taken and qtd_copy_status() returns EPROTO. This
> >> return value in qh_completions() results in ehci_clear_tt_buffer()
> >> being called:

I didn't mention this before, but that combination of events doesn't 
make sense.  The MMF bit is supposed to get set only for queue heads in 
the periodic list, that is, only for interrupt transactions.  But 
ehci_clear_tt_buffer() doesn't do anything for interrupt endpoints; it 
tests specifically for that right at the start.

Maybe your EHCI controller is setting the MMF bit when it shouldn't.  
The usbmon output will help clear this up.

Or maybe the hubs you are testing don't work right.  That's the only 
reason I can think of for the failures you see with the USB-3 
controller; the way it operates is very different from the way EHCI 
does.

Alan Stern