1. 22 5月, 2018 10 次提交
  2. 18 5月, 2018 1 次提交
  3. 17 5月, 2018 1 次提交
    • S
      usbip: usbip_host: fix bad unlock balance during stub_probe() · c171654c
      Shuah Khan (Samsung OSG) 提交于
      stub_probe() calls put_busid_priv() in an error path when device isn't
      found in the busid_table. Fix it by making put_busid_priv() safe to be
      called with null struct bus_id_priv pointer.
      
      This problem happens when "usbip bind" is run without loading usbip_host
      driver and then running modprobe. The first failed bind attempt unbinds
      the device from the original driver and when usbip_host is modprobed,
      stub_probe() runs and doesn't find the device in its busid table and calls
      put_busid_priv(0 with null bus_id_priv pointer.
      
      usbip-host 3-10.2: 3-10.2 is not in match_busid table...  skip!
      
      [  367.359679] =====================================
      [  367.359681] WARNING: bad unlock balance detected!
      [  367.359683] 4.17.0-rc4+ #5 Not tainted
      [  367.359685] -------------------------------------
      [  367.359688] modprobe/2768 is trying to release lock (
      [  367.359689]
      ==================================================================
      [  367.359696] BUG: KASAN: null-ptr-deref in print_unlock_imbalance_bug+0x99/0x110
      [  367.359699] Read of size 8 at addr 0000000000000058 by task modprobe/2768
      
      [  367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5
      
      Fixes: 22076557 ("usbip: usbip_host: fix NULL-ptr deref and use-after-free errors") in usb-linus
      Signed-off-by: NShuah Khan (Samsung OSG) <shuah@kernel.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c171654c
  4. 15 5月, 2018 4 次提交
  5. 14 5月, 2018 2 次提交
    • D
      usb: musb: fix remote wakeup racing with suspend · ebc3dd68
      Daniel Glöckner 提交于
      It has been observed that writing 0xF2 to the power register while it
      reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
      RESUME and setting SUSPENDM in one go does not work. It might also violate
      the USB spec to transition directly from resume to suspend, especially
      when not taking T_DRSMDN into account. But this is what happens when a
      remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the
      root hub and musb_bus_suspend being called.
      
      This commit returns -EBUSY when musb_bus_suspend is called while remote
      wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring
      this error when musb_port_suspend is called from musb_hub_control is ok.
      Signed-off-by: NDaniel Glöckner <dg@emlix.com>
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebc3dd68
    • M
      xhci: Fix USB3 NULL pointer dereference at logical disconnect. · 2278446e
      Mathias Nyman 提交于
      Hub driver will try to disable a USB3 device twice at logical disconnect,
      racing with xhci_free_dev() callback from the first port disable.
      
      This can be triggered with "udisksctl power-off --block-device <disk>"
      or by writing "1" to the "remove" sysfs file for a USB3 device
      in 4.17-rc4.
      
      USB3 devices don't have a similar disabled link state as USB2 devices,
      and use a U3 suspended link state instead. In this state the port
      is still enabled and connected.
      
      hub_port_connect() first disconnects the device, then later it notices
      that device is still enabled (due to U3 states) it will try to disable
      the port again (set to U3).
      
      The xhci_free_dev() called during device disable is async, so checking
      for existing xhci->devs[i] when setting link state to U3 the second time
      was successful, even if device was being freed.
      
      The regression was caused by, and whole thing revealed by,
      Commit 44a182b9 ("xhci: Fix use-after-free in xhci_free_virt_device")
      which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned.
      and causes a NULL pointer dereference the second time we try to set U3.
      
      Fix this by checking xhci->devs[i]->udev exists before setting link state.
      
      The original patch went to stable so this fix needs to be applied there as
      well.
      
      Fixes: 44a182b9 ("xhci: Fix use-after-free in xhci_free_virt_device")
      Cc: <stable@vger.kernel.org>
      Reported-by: NJordan Glover <Golden_Miller83@protonmail.ch>
      Tested-by: NJordan Glover <Golden_Miller83@protonmail.ch>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2278446e
  6. 05 5月, 2018 1 次提交
    • G
      Revert "usb: host: ehci: Use dma_pool_zalloc()" · 43b78f11
      Greg Kroah-Hartman 提交于
      This reverts commit 22072e83 as it is
      broken.
      
      Alan writes:
      	What you can't see just from reading the patch is that in both
      	cases (ehci->itd_pool and ehci->sitd_pool) there are two
      	allocation paths -- the two branches of an "if" statement -- and
      	only one of the paths calls dma_pool_[z]alloc.  However, the
      	memset is needed for both paths, and so it can't be eliminated.
      	Given that it must be present, there's no advantage to calling
      	dma_pool_zalloc rather than dma_pool_alloc.
      Reported-by: NErick Cafferata <erick@cafferata.me>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43b78f11
  7. 04 5月, 2018 5 次提交
  8. 03 5月, 2018 1 次提交
  9. 02 5月, 2018 2 次提交
  10. 01 5月, 2018 3 次提交
  11. 29 4月, 2018 1 次提交
  12. 25 4月, 2018 9 次提交