linux-stable.git/drivers/usb/core, branch linux-4.8.y

usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

2017-01-06T10:16:19+00:00

commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 upstream.

USB-3 does not have any link state that will avoid negotiating a connection
with a plugged-in cable but will signal the host when the cable is
unplugged.

For USB-3 we used to first set the link to Disabled, then to RxDdetect to
be able to detect cable connects or disconnects. But in RxDetect the
connected device is detected again and eventually enabled.

Instead set the link into U3 and disable remote wakeups for the device.
This is what Windows does, and what Alan Stern suggested.

Cc: Alan Stern 
Acked-by: Alan Stern 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: change bInterval default to 10 ms

2016-09-16T14:29:41+00:00

Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.

Signed-off-by: Alan Stern 
Tested-by: Wade Berrier 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: avoid left shift by -1

2016-08-23T20:35:20+00:00

UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
can occur when an URB is submitted for a bulk or control endpoint on
a high-speed device, since the code doesn't bother to check the
endpoint type; normally only interrupt or isochronous endpoints have
a nonzero bInterval value.

Aside from the fact that the operation is illegal, it shouldn't matter
because the result isn't used.  Still, in theory it could cause a
hardware exception or other problem, so we should work around it.
This patch avoids doing the left shift unless the shift amount is >= 0.

The same piece of code has another problem.  When checking the device
speed (the exponential encoding for interrupt endpoints is used only
by high-speed or faster devices), we need to look for speed >=
USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
this check.

Signed-off-by: Alan Stern 
Reported-by: Vittorio Zecca 
Tested-by: Vittorio Zecca 
Suggested-by: Bjørn Mork 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: fix typo in wMaxPacketSize validation

2016-08-23T10:54:32+00:00

The maximum value allowed for wMaxPacketSize of a high-speed interrupt
endpoint is 1024 bytes, not 1023.

Signed-off-by: Alan Stern 
Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: remove race condition in usbfs/libusb when using reap-after-disconnect

2016-08-09T14:14:18+00:00

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: Alan Stern 
Reported-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

usb: devio, do not warn when allocation fails

2016-08-09T14:14:18+00:00

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:
 [] ? warn_slowpath_null+0x2e/0x40
 [] ? __alloc_pages_slowpath+0x1036/0x16e0
 [] ? warn_alloc_failed+0x250/0x250
 [] ? get_page_from_freelist+0x75b/0x28b0
 [] ? __alloc_pages_nodemask+0x583/0x6b0
 [] ? __alloc_pages_slowpath+0x16e0/0x16e0
 [] ? dma_generic_alloc_coherent+0x104/0x220
 [] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore]
 [] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore]
 [] ? usb_alloc_coherent+0x65/0x90 [usbcore]
 [] ? 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: Jiri Slaby 
Cc: Greg Kroah-Hartman 
Cc: Alan Stern 
Cc: Steinar H. Gunderson 
Cc: Markus Rechberger 
Fixes: f7d34b445a (USB: Add support for usbfs zerocopy.)
Cc: 4.6+ 
Signed-off-by: Greg Kroah-Hartman

USB: validate wMaxPacketValue entries in endpoint descriptors

2016-08-09T14:14:18+00:00

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
, an intern working for Rosie Hall.

Signed-off-by: Alan Stern 
Reported-by: roswest 
Tested-by: roswest 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: hub: change the locking in hub_activate

2016-08-09T13:45:59+00:00

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: Alan Stern 
CC:  #4.4+
Signed-off-by: Greg Kroah-Hartman

USB: hub: fix up early-exit pathway in hub_activate

2016-08-09T13:45:59+00:00

The early-exit pathway in hub_activate, added by commit e50293ef9775
("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: Alan Stern 
CC:  #4.4+
Reviewed-by: Viresh Kumar 
Signed-off-by: Greg Kroah-Hartman

usb: hub: Fix unbalanced reference count/memory leak/deadlocks

2016-08-09T13:45:59+00:00

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 e50293ef9775 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:
    [] create_object+0x148/0x2a0
    [] kmemleak_alloc+0x80/0xbc
    [] kmem_cache_alloc_trace+0x120/0x1ac
    [] hub_probe+0x120/0xb84
    [] usb_probe_interface+0x1ec/0x298
    [] driver_probe_device+0x160/0x374
    [] __device_attach+0x28/0x4c
    [] bus_for_each_drv+0x78/0xac
    [] device_attach+0x6c/0x9c
    [] bus_probe_device+0x28/0xa0
    [] device_add+0x324/0x604
    [] usb_set_configuration+0x660/0x6cc
    [] generic_probe+0x44/0x84
    [] usb_probe_device+0x54/0x74
    [] driver_probe_device+0x160/0x374
    [] __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:  #4.4+
Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()")
Reported-by: Manu Gautam 
Signed-off-by: Viresh Kumar 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman