1. 19 12月, 2015 1 次提交
    • A
      USB: fix invalid memory access in hub_activate() · e50293ef
      Alan Stern 提交于
      Commit 8520f380 ("USB: change hub initialization sleeps to
      delayed_work") changed the hub_activate() routine to make part of it
      run in a workqueue.  However, the commit failed to take a reference to
      the usb_hub structure or to lock the hub interface while doing so.  As
      a result, if a hub is plugged in and quickly unplugged before the work
      routine can run, the routine will try to access memory that has been
      deallocated.  Or, if the hub is unplugged while the routine is
      running, the memory may be deallocated while it is in active use.
      
      This patch fixes the problem by taking a reference to the usb_hub at
      the start of hub_activate() and releasing it at the end (when the work
      is finished), and by locking the hub interface while the work routine
      is running.  It also adds a check at the start of the routine to see
      if the hub has already been disconnected, in which nothing should be
      done.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NAlexandru Cornea <alexandru.cornea@intel.com>
      Tested-by: NAlexandru Cornea <alexandru.cornea@intel.com>
      Fixes: 8520f380 ("USB: change hub initialization sleeps to delayed_work")
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e50293ef
  2. 12 12月, 2015 1 次提交
  3. 05 12月, 2015 1 次提交
    • D
      usb: Quiet down false peer failure messages · 6406eeb3
      Don Zickus 提交于
      My recent Intel box is spewing these messages:
      
      xhci_hcd 0000:00:14.0: xHCI Host Controller
      xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
      usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
      usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
      usb usb2: Product: xHCI Host Controller
      usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
      usb usb2: SerialNumber: 0000:00:14.0
      hub 2-0:1.0: USB hub found
      hub 2-0:1.0: 6 ports detected
      usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) (usb1-port1:usb2-port1)
      usb usb2-port2: failed to peer to usb1-port1 (-16)
      usb: port power management may be unreliable
      usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) (usb1-port1:usb2-port1)
      usb usb2-port3: failed to peer to usb1-port1 (-16)
      usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) (usb1-port1:usb2-port1)
      usb usb2-port5: failed to peer to usb1-port1 (-16)
      usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) (usb1-port1:usb2-port1)
      usb usb2-port6: failed to peer to usb1-port1 (-16)
      
      Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
      hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
      (including port 1 of the EHCI hub).
      
      Further the unused ports have location data initialized to 0x80000000.
      
      Now each unused port on the xhci hub walks the port list and finds a matching
      peer with port1 of the EHCI hub because the zero'd out group id bits falsely match.
      After port1 of the XHCI hub, each following matching peer will generate the
      above warning.
      
      These warnings seem to be harmless for this scenario as I don't think it
      matters that unused ports could not create a peer link.
      
      The attached patch utilizes that assumption and just turns the pr_warn into
      pr_debug to quiet things down.
      
      Tested on my Intel box.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6406eeb3
  4. 02 12月, 2015 3 次提交
    • B
      usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message · 5377adb0
      Ben Hutchings 提交于
      usb_parse_ss_endpoint_companion() now decodes the burst multiplier
      correctly in order to check that it's <= 3, but still uses the wrong
      expression if warning that it's > 3.
      
      Fixes: ff30cbc8 ("usb: Use the USB_SS_MULT() macro to get the ...")
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5377adb0
    • H
      usb: core : hub: Fix BOS 'NULL pointer' kernel panic · 464ad8c4
      Hans Yang 提交于
      When a USB 3.0 mass storage device is disconnected in transporting
      state, storage device driver may handle it as a transport error and
      reset the device by invoking usb_reset_and_verify_device()
      and following could happen:
      
      in usb_reset_and_verify_device():
         udev->bos = NULL;
      
      For U1/U2 enabled devices, driver will disable LPM, and in some
      conditions:
         from usb_unlocked_disable_lpm()
          --> usb_disable_lpm()
          --> usb_enable_lpm()
              udev->bos->ss_cap->bU1devExitLat;
      
      And it causes 'NULL pointer' and 'kernel panic':
      
      [  157.976257] Unable to handle kernel NULL pointer dereference
      at virtual address 00000010
      ...
      [  158.026400] PC is at usb_enable_link_state+0x34/0x2e0
      [  158.031442] LR is at usb_enable_lpm+0x98/0xac
      ...
      [  158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0
      [  158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac
      [  158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4
      ...
      [  158.214954] Kernel panic - not syncing: Fatal exception
      
      This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
      to prevent from NULL pointer access.
      
      Issue can be reproduced by following setup:
      1) A SS pen drive behind a SS hub connected to the host.
      2) Transporting data between the pen drive and the host.
      3) Abruptly disconnect hub and pen drive from host.
      4) With a chance it crashes.
      Signed-off-by: NHans Yang <hansy@nvidia.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      464ad8c4
    • A
      USB: quirks: Fix another ELAN touchscreen · df36c5be
      Adrien Vergé 提交于
      Like other buggy models that had their fixes [1], the touchscreen with
      id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
      quirk. Otherwise, it fails to respond, blocks the boot for a random
      amount of time and pollutes dmesg with:
      
      [ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
      [ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
      [ 2889.502005] usb 1-5: can't read configurations, error -71
      [ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
      [ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
      [ 2891.783443] usb 1-5: can't read configurations, error -71
      
      [1]: See commits c68929f7, 876af5d4, d7499475, a32c99e7 and dc703ec2.
      Tested-by: NAdrien Vergé <adrienverge@gmail.com>
      Signed-off-by: NAdrien Vergé <adrienverge@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df36c5be
  5. 20 11月, 2015 2 次提交
  6. 26 10月, 2015 1 次提交
  7. 17 10月, 2015 1 次提交
  8. 04 10月, 2015 9 次提交
  9. 23 9月, 2015 5 次提交
  10. 22 9月, 2015 1 次提交
  11. 19 8月, 2015 5 次提交
  12. 15 8月, 2015 9 次提交
  13. 09 8月, 2015 1 次提交