linux-kernel - /drivers/usb/core/hub.c: USB3 devices "lost for good" when in SS.inactive or Compliance Mode

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

Message-ID: <trinity-e9278a4b-93a8-4a81-aed9-4a46db77d499-1432051153309@3capp-gmx-bs25>
Date:	Tue, 19 May 2015 17:59:13 +0200
From:	"Robert Schlabbach" <Robert.Schlabbach@....net>
To:	linux-kernel@...r.kernel.org
Subject: /drivers/usb/core/hub.c: USB3 devices "lost for good" when in
 SS.inactive or Compliance Mode - intended behavior?

Dear Linux kernel experts,

I recently ran into an issue where Linux (kernel 3.19.0-16 amd64 from
Ubuntu 15.04) would frequently "lose" a USB 3.0 stick it was supposed
to boot from and bomb out because it couldn't mount the root fs.

Upon closer investigation, I found that the hub port the USB 3.0 stick
is connected to apparently likes to go into SS.inactive state at
initialization. Now looking at the code, it looks as if a "warm reset"
is supposed to fix that. But in fact, it can't. Here's a crude draft
of the calls inside /drivers/usb/core/hub.c I observed:

1. hub_port_reset()
2. > hub_port_wait_reset()
3. > > hub_port_status() returns port status 0x02C0
       (link state = USB_SS_PORT_LS_SS_INACTIVE)
4. > > hub_port_warm_reset_required() returns TRUE due to
       link_state == USB_SS_PORT_LS_SS_INACTIVE
5. > hub_port_wait_reset() returns -ENOTCONN due to the TRUE result
     from hub_port_warm_reset_required()
6. > hub_port_finish_reset(... *status = -ENOTCONN)
7. > > usb_set_device_state(udev, USB_STATE_NOTATTACHED)

And that's the problem: USB device state USB_STATE_NOTATTACHED is a
dead end as usb_set_device_state() does not seem to allow ever leaving
that state:

if (udev->state == USB_STATE_NOTATTACHED) {
  ; /* do nothing */
}

Is that the intended behavior, that once a hub port goes into SS.inactive
or Compliance Mode state, the USB devices connected to it are left
inoperable even after a warm reset and have to be physically unplugged
and replugged to be used again?

I tried altering the end of hub_port_finish_reset() to:

  if (udev)
   usb_set_device_state(udev, *status
     ? USB_STATE_ATTACHED // FIX: was USB_STATE_NOTATTACHED
     : USB_STATE_DEFAULT);

and that fixed the problem I was seeing, but I'm not sure if this is the
proper way to fix this, or if it should be fixed e.g. in hub_port_reset()
when it knows that a warm reset will still be tried.

Any thoughts?

Best Regards,
-Robert Schlabbach
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/