1. 16 Aug, 2016 1 commit
    • Mathias Nyman's avatar
      xhci: always handle "Command Ring Stopped" events · 33be1265
      Mathias Nyman authored
      Fix "Command completion event does not match command" errors by always
      handling the command ring stopped events.
      
      The command ring stopped event is generated as a result of aborting
      or stopping the command ring with a register write. It is not caused
      by a command in the command queue, and thus won't have a matching command
      in the comman list.
      
      Solve it by handling the command ring stopped event before checking for a
      matching command.
      
      In most command time out cases we abort the command ring, and get
      a command ring stopped event. The events command pointer will point at
      the current command ring dequeue, which in most cases matches the timed
      out command in the command list, and no error messages are seen.
      
      If we instead get a command aborted event before the command ring stopped
      event, the abort event will increse the command ring dequeue pointer, and
      the following command ring stopped events command pointer will point at the
      next, not yet queued command. This case triggered the error message
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33be1265
  2. 15 Aug, 2016 1 commit
  3. 12 Aug, 2016 1 commit
  4. 11 Aug, 2016 20 commits
  5. 10 Aug, 2016 4 commits
  6. 09 Aug, 2016 10 commits
    • Jaewon Kim's avatar
      usb: host: max3421-hcd: fix mask of IO control register · 59b71f77
      Jaewon Kim authored
      GPIO control register is divided into IOPINS1 and IOPINS2.
      And low 4-bit of register is controls output.
      
      So, this patch fixes wrong mask of GPIO output.
      Signed-off-by: default avatarJaewon Kim <jaewon02.kim@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59b71f77
    • Alan Stern's avatar
      USB: remove race condition in usbfs/libusb when using reap-after-disconnect · 5cce4382
      Alan Stern authored
      Hans de Goede has reported a difficulty in the Linux port of libusb.
      When a device is removed, the poll() system call in usbfs starts
      returning POLLERR as soon as udev->state is set to
      USB_STATE_NOTATTACHED, but the outstanding URBs are not available for
      reaping until some time later (after usbdev_remove() has been called).
      This is awkward for libusb or other usbfs clients, although not an
      insuperable problem.
      
      At any rate, it's easy to change usbfs so that it returns POLLHUP as
      soon as the state becomes USB_STATE_NOTATTACHED but it doesn't return
      POLLERR until after the outstanding URBs have completed.  That's what
      this patch does; it uses the fact that ps->list is always on the
      dev->filelist list until usbdev_remove() takes it off, which happens
      after all the outstanding URBs have been cancelled.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cce4382
    • Jiri Slaby's avatar
      usb: devio, do not warn when allocation fails · 70f7ca9a
      Jiri Slaby authored
      usbdev_mmap allocates a buffer. The size of the buffer is determined
      by a user. So with this code (no need to be root):
      
      	int fd = open("/dev/bus/usb/001/001", O_RDONLY);
      	mmap(NULL, 0x800000, PROT_READ, MAP_SHARED, fd, 0);
      
      we can see a warning:
      
      WARNING: CPU: 0 PID: 21771 at ../mm/page_alloc.c:3563 __alloc_pages_slowpath+0x1036/0x16e0()
      ...
      Call Trace:
       [<ffffffff8117a3ae>] ? warn_slowpath_null+0x2e/0x40
       [<ffffffff815178b6>] ? __alloc_pages_slowpath+0x1036/0x16e0
       [<ffffffff81516880>] ? warn_alloc_failed+0x250/0x250
       [<ffffffff8151226b>] ? get_page_from_freelist+0x75b/0x28b0
       [<ffffffff815184e3>] ? __alloc_pages_nodemask+0x583/0x6b0
       [<ffffffff81517f60>] ? __alloc_pages_slowpath+0x16e0/0x16e0
       [<ffffffff810565d4>] ? dma_generic_alloc_coherent+0x104/0x220
       [<ffffffffa0269e56>] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore]
       [<ffffffffa0269c80>] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore]
       [<ffffffffa0228f05>] ? usb_alloc_coherent+0x65/0x90 [usbcore]
       [<ffffffffa0275c05>] ? usbdev_mmap+0x1a5/0x770 [usbcore]
      ...
      
      Allocations like this one should be marked as __GFP_NOWARN. So do so.
      
      The size could be also clipped by something like:
      	if (size >= (1 << (MAX_ORDER + PAGE_SHIFT - 1)))
      		return -ENOMEM;
      But I think the overall limit of 16M (by usbfs_increase_memory_usage)
      is enough, so that we only silence the warning here.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Steinar H. Gunderson <sesse@google.com>
      Cc: Markus Rechberger <mrechberger@gmail.com>
      Fixes: f7d34b44 (USB: Add support for usbfs zerocopy.)
      Cc: 4.6+ <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70f7ca9a
    • Marc Ohlf's avatar
      usb: ehci: change order of register cleanup during shutdown · bc337b51
      Marc Ohlf authored
      In ehci_turn_off_all_ports() all EHCI port registers are cleared to zero.
      On some hardware, this can lead to an system hang,
      when ehci_port_power() accesses the already cleared registers.
      
      This patch changes the order of cleanup.
      First call ehci_port_power() which respects the current bits in
      port status registers
      and afterwards cleanup the hard way by setting everything to zero.
      Signed-off-by: default avatarMarc Ohlf <ohlf@mkt-sys.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc337b51
    • Alan Stern's avatar
      USB: validate wMaxPacketValue entries in endpoint descriptors · aed9d65a
      Alan Stern authored
      Erroneous or malicious endpoint descriptors may have non-zero bits in
      reserved positions, or out-of-bounds values.  This patch helps prevent
      these from causing problems by bounds-checking the wMaxPacketValue
      entries in endpoint descriptors and capping the values at the maximum
      allowed.
      
      This issue was first discovered and tests were conducted by Jake Lamberson
      <jake.lamberson1@gmail.com>, an intern working for Rosie Hall.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarroswest <roswest@cisco.com>
      Tested-by: default avatarroswest <roswest@cisco.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aed9d65a
    • Xiao Han's avatar
      usb: misc: ftdi-elan: Fix off-by-one memory corruptions · 9c6256a5
      Xiao Han authored
      This patch fixes fives off-by-one bugs in the ftdi-elan driver code. The
      bug can be triggered by plugging a USB adapter for CardBus 3G cards (model
      U132 manufactured by Elan Digital Systems, Ltd), causing a kernel panic.
      The fix was tested on Ubuntu 14.04.4 with 4.7.0-rc14.2.0-27-generic+ and
      4.4.0-22-generic+ kernel. In the ftdi_elan_synchronize function, an
      off-by-one memory corruption occurs when packet_bytes is equal or bigger
      than m. After having read m bytes, that is bytes_read is equal to m, "
      ..\x00" is still copied to the stack variable causing an out bounds write
      of 4 bytes, which overwrites the stack canary and results in a kernel
      panic.
      
      This off-by-one requires physical access to the machine. It is not
      exploitable since we have no control on the overwritten data.  Similar
      off-by-one bugs have been observed in 4 other functions:
      ftdi_elan_stuck_waiting, ftdi_elan_read, ftdi_elan_edset_output and
      ftdi_elan_flush_input_fifo.
      Reported-by: default avatarAlex Palesandro <palexster@gmail.com>
      Signed-off-by: default avatarXiao Han <xiao.han@orange.fr>
      Tested-by: default avatarPaul Chaignon <pchaigno@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c6256a5
    • Peter Chen's avatar
      usb: misc: usbtest: usbtest_do_ioctl may return positive integer · 28324936
      Peter Chen authored
      For case 14 and case 21, their correct return value is the number
      of bytes transferred, so it is a positive integer. But in usbtest_ioctl,
      it takes non-zero as false return value for usbtest_do_ioctl, so
      it will treat the correct test as wrong test, then the time on
      tests will be the minus value.
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Cc: stable <stable@vger.kernel.org>
      Fixes: 18fc4ebd ("usb: misc: usbtest: Remove timeval usage")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28324936
    • Alan Stern's avatar
      USB: hub: change the locking in hub_activate · 07d316a2
      Alan Stern authored
      The locking in hub_activate() is not adequate to provide full mutual
      exclusion with hub_quiesce().  The subroutine locks the hub's
      usb_interface, but the callers of hub_quiesce() (such as
      hub_pre_reset() and hub_event()) hold the lock to the hub's
      usb_device.
      
      This patch changes hub_activate() to make it acquire the same lock as
      those other routines.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org> #4.4+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d316a2
    • Alan Stern's avatar
      USB: hub: fix up early-exit pathway in hub_activate · ca5cbc8b
      Alan Stern authored
      The early-exit pathway in hub_activate, added by commit e50293ef
      ("USB: fix invalid memory access in hub_activate()") needs
      improvement.  It duplicates code that is already present at the end of
      the subroutine, and it neglects to undo the effect of a
      usb_autopm_get_interface_no_resume() call.
      
      This patch fixes both problems by making the early-exit pathway jump
      directly to the end of the subroutine.  It simplifies the code at the
      end by merging two conditionals that actually test the same condition
      although they appear different: If type < HUB_INIT3 then type must be
      either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that
      case the subroutine would have exited earlier.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org> #4.4+
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca5cbc8b
    • Viresh Kumar's avatar
      usb: hub: Fix unbalanced reference count/memory leak/deadlocks · 6bb47e8a
      Viresh Kumar authored
      Memory leak and unbalanced reference count:
      
      If the hub gets disconnected while the core is still activating it, this
      can result in leaking memory of few USB structures.
      
      This will happen if we have done a kref_get() from hub_activate() and
      scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
      gets called before the delayed work expires, then we will cancel the
      work from hub_quiesce(), but wouldn't do a kref_put(). And so the
      unbalance.
      
      kmemleak reports this as (with the commit e50293ef backported to
      3.10 kernel with other changes, though the same is true for mainline as
      well):
      
      unreferenced object 0xffffffc08af5b800 (size 1024):
        comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s)
        hex dump (first 32 bytes):
          30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff  0h..............
          01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff  ..........}@....
        backtrace:
          [<ffffffc0003079ec>] create_object+0x148/0x2a0
          [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc
          [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac
          [<ffffffc0006fa610>] hub_probe+0x120/0xb84
          [<ffffffc000702b20>] usb_probe_interface+0x1ec/0x298
          [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
          [<ffffffc0005d5308>] __device_attach+0x28/0x4c
          [<ffffffc0005d3164>] bus_for_each_drv+0x78/0xac
          [<ffffffc0005d4ee0>] device_attach+0x6c/0x9c
          [<ffffffc0005d42b8>] bus_probe_device+0x28/0xa0
          [<ffffffc0005d23a4>] device_add+0x324/0x604
          [<ffffffc000700fcc>] usb_set_configuration+0x660/0x6cc
          [<ffffffc00070a350>] generic_probe+0x44/0x84
          [<ffffffc000702914>] usb_probe_device+0x54/0x74
          [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
          [<ffffffc0005d5308>] __device_attach+0x28/0x4c
      
      Deadlocks:
      
      If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are
      finished and the init_work is still queued), the core may call
      hub_quiesce() after acquiring interface device locks and it will wait
      for the work to be cancelled synchronously. But if the work handler is
      already running in parallel, it may try to acquire the same interface
      device lock and this may result in deadlock.
      
      Fix both the issues by removing the call to cancel_delayed_work_sync().
      
      CC: <stable@vger.kernel.org> #4.4+
      Fixes: e50293ef ("USB: fix invalid memory access in hub_activate()")
      Reported-by: default avatarManu Gautam <mgautam@codeaurora.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bb47e8a
  7. 08 Aug, 2016 3 commits