1. 09 Sep, 2016 1 commit
    • Clemens Gruber's avatar
      usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase · 6f3c4fb6
      Clemens Gruber authored
      Problems with the signal integrity of the high speed USB data lines or
      noise on reference ground lines can cause the i.MX6 USB controller to
      violate USB specs and exhibit unexpected behavior.
      
      It was observed that USBi_UI interrupts were triggered first and when
      isr_setup_status_phase was called, ci->status was NULL, which lead to a
      NULL pointer dereference kernel panic.
      
      This patch fixes the kernel panic, emits a warning once and returns
      -EPIPE to halt the device and let the host get stalled.
      It also adds a comment to point people, who are experiencing this issue,
      to their USB hardware design.
      
      Cc: <stable@vger.kernel.org> #4.1+
      Signed-off-by: default avatarClemens Gruber <clemens.gruber@pqgruber.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      6f3c4fb6
  2. 19 Aug, 2016 1 commit
  3. 16 Aug, 2016 4 commits
    • Mathias Nyman's avatar
      xhci: don't dereference a xhci member after removing xhci · f1f6d9a8
      Mathias Nyman authored
      Remove the hcd after checking for the xhci last quirks, not before.
      
      This caused a hang on a Alpine Ridge xhci based maching which remove
      the whole xhci controller when unplugging the last usb device
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1f6d9a8
    • Jim Lin's avatar
      usb: xhci: Fix panic if disconnect · 88716a93
      Jim Lin authored
      After a device is disconnected, xhci_stop_device() will be invoked
      in xhci_bus_suspend().
      Also the "disconnect" IRQ will have ISR to invoke
      xhci_free_virt_device() in this sequence.
      xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
      xhci_handle_cmd_disable_slot -> xhci_free_virt_device
      
      If xhci->devs[slot_id] has been assigned to NULL in
      xhci_free_virt_device(), then virt_dev->eps[i].ring in
      xhci_stop_device() may point to an invlid address to cause kernel
      panic.
      
      virt_dev = xhci->devs[slot_id];
      :
      if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
      
      [] Unable to handle kernel paging request at virtual address 00001a68
      [] pgd=ffffffc001430000
      [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003,
      *pmd=000000013c808003, *pte=0000000000000000
      [] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G     U
      [] Workqueue: pm pm_runtime_work
      [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti:
      ffffffc0bc0ec000
      [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4
      
      This issue is found when running with realtek ethernet device
      (0bda:8153).
      Signed-off-by: default avatarJim Lin <jilin@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88716a93
    • Alban Browaeys's avatar
      xhci: really enqueue zero length TRBs. · 0d2daade
      Alban Browaeys authored
      Enqueue the first TRB even if full_len is zero.
      Without this "adb install <apk>" freezes the system.
      Signed-off-by: default avatarAlban Browaeys <alban.browaeys@gmail.com>
      Fixes: 86065c27 ("xhci: don't rely on precalculated value of needed trbs in the enqueue loop")
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d2daade
    • 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
  4. 15 Aug, 2016 1 commit
  5. 12 Aug, 2016 1 commit
  6. 11 Aug, 2016 20 commits
  7. 10 Aug, 2016 4 commits
  8. 09 Aug, 2016 8 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