linux-kernel - Re: Regression: plugging in USB scanner breaks all USB functionality

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: <d9fb7e699dd0d8528a3dcfd83ad33614bde4373e.camel@apache.org>
Date:   Fri, 03 Dec 2021 16:33:23 +0100
From:   Robert Munteanu <rombert@...che.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mathias Nyman <mathias.nyman@...el.com>, tiwai@...e.com,
        regressions@...ts.linux.dev, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Regression: plugging in USB scanner breaks all USB functionality

On Thu, 2021-12-02 at 16:17 +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 02, 2021 at 03:55:44PM +0100, Robert Munteanu wrote:
> > Hi,
> > 
> > After updating from kernel 5.14.11 to 5.14.14 I am seeing the
> > following
> > problem:
> 
> Can you run 'git bisect' between those kernel versions to get the
> offending commit located?  It shouldn't take that long as there's not a
> lot of changes there.

A full bisect run, as suspected in other messages, results in

e54abefe703ab7c4e5983e889babd1447738ca42 is the first bad commit
commit e54abefe703ab7c4e5983e889babd1447738ca42
Author: Pavankumar Kondeti <pkondeti@...eaurora.org>
Date:   Fri Oct 8 12:25:46 2021 +0300

    xhci: Fix command ring pointer corruption while aborting a command
    
    commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.
    
    The command ring pointer is located at [6:63] bits of the command
    ring control register (CRCR). All the control bits like command
stop,
    abort are located at [0:3] bits. While aborting a command, we read
the
    CRCR and set the abort bit and write to the CRCR. The read will
always
    give command ring pointer as all zeros. So we essentially write
only
    the control bits. Since we split the 64 bit write into two 32 bit
writes,
    there is a possibility of xHC command ring stopped before the upper
    dword (all zeros) is written. If that happens, xHC updates the
upper
    dword of its internal command ring pointer with all zeros. Next
time,
    when the command ring is restarted, we see xHC memory access
failures.
    Fix this issue by only writing to the lower dword of CRCR where all
    control bits are located.
    
    Cc: stable@...r.kernel.org
    Signed-off-by: Pavankumar Kondeti <pkondeti@...eaurora.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@...ux.intel.com>
    Link:
https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

 drivers/usb/host/xhci-ring.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

I will try the patch linked by Matias as soon as the openSUSE kernel
build is complete.

Thanks,
Robert