Skip to content

L
linux
Switch branch/tag
  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
  3. 15 Aug, 2016 1 commit
  5. 12 Aug, 2016 1 commit
  7. 11 Aug, 2016 20 commits
  9. 10 Aug, 2016 4 commits
  11. 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
  13. 08 Aug, 2016 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7