linux-kernel - Re: [PATCH] usb: host: xhci: Replace bus lock with host controller lock

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] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2016 18:50:06 +0200
From:	Mathias Nyman <mathias.nyman@...ux.intel.com>
To:	Chris Bainbridge <chris.bainbridge@...il.com>,
	Alan Stern <stern@...land.harvard.edu>
CC:	johan@...nel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: host: xhci: Replace bus lock with host controller
 lock

On 05.02.2016 17:14, Chris Bainbridge wrote:
> Running task list at fail point:

...

> Some of the functions appear to be inlined, the exact call chain is:
>
> hub_port_init
>      usb_get_device_descriptor
>          usb_get_descriptor
>              usb_control_msg
>                  usb_internal_control_msg
>                      usb_start_wait_urb
>                          usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
>
> hub_port_init
>      hub_set_address
>          xhci_address_device
>              xhci_setup_device
>

hub_port_reset() will end up moving the corresponding xhci device slot to default state.

As hub_port_reset() is called several times in hub_port_init() It sounds reasonable
that we could end up with two threads having their xhci device slots in default state at
the same time,  which according to xhci 4.5.3 specs still is a big no no.

So both threads fail at their next task after this.
One fails to read the descriptor, and the other fails addressing the device.

Nice catch btw.

> So xhci_setup_device is entered while there is an outstanding URB on the
> other bus. Unless anyone can think of a better way to fix this I'll make
> the requested changes and resend my patch.
>

For what it's wort I think that this suggested controller mutex sounds like a good idea.
Should work for xhci at least.

-Mathias