xavi/android_kernel_m2note/drivers/usb/core, branch o-8.1

Replace with globally

2018-11-29T17:33:35+00:00

This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*' sed -i -e "s!$PATT!#include !" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Moyster

USB: core: only clean up what we allocated

2018-11-29T17:33:28+00:00

When cleaning up the configurations, make sure we only free the number of configurations and interfaces that we could have allocated. Change-Id: I07a2ddd088264030544284ad9680cd6d2b538d21 Reported-by: Andrey Konovalov Cc: stable Signed-off-by: Greg Kroah-Hartman Git-commit: 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Srinivasa Rao Kuppala Signed-off-by: Dheeraj Kumar Chaudhary Signed-off-by: Richard JK

usb: replace %p with %pK

2018-11-27T16:09:47+00:00

Format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's. Debugging Note : &pK prints only Zeros as address. If you need actual address information, write 0 to kptr_restrict. echo 0 > /proc/sys/kernel/kptr_restrict CRs-fixed: 1052849 Change-Id: I0e98145730380ea983fa8f46a28d15dd6c2c31df Signed-off-by: Manu Gautam Signed-off-by: Yasir Malik Signed-off-by: Kevin F. Haggerty

UPSTREAM: USB: fix out-of-bounds in usb_set_configuration

2017-11-18T18:14:56+00:00

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes: It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount. And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller... Change-Id: I2cc3b5a66d16abd0fc567d69457fc90a45eb12d8 Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Cc: stable Signed-off-by: Greg Kroah-Hartman

UPSTREAM: USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()

2017-11-18T18:11:35+00:00

commit 1c0edc3633b56000e18d82fc241e3995ca18a69e Andrey used the syzkaller fuzzer to find an out-of-bounds memory access in usb_get_bos_descriptor(). The code wasn't checking that the next usb_dev_cap_header structure could fit into the remaining buffer space. This patch fixes the error and also reduces the bNumDeviceCaps field in the header to match the actual number of capabilities found, in cases where there are fewer than expected. Change-Id: Ica990541695ce5ba46ca8d2bd01e8230dcf5dcd4 Reported-by: Andrey Konovalov Signed-off-by: Alan Stern Tested-by: Andrey Konovalov CC: Signed-off-by: Greg Kroah-Hartman

usb: hub: Wait for connection to be reestablished after port reset

2017-07-02T17:41:28+00:00

commit 22547c4cc4fe20698a6a85a55b8788859134b8e4 upstream. On a system with a defective USB device connected to an USB hub, an endless sequence of port connect events was observed. The sequence of events as observed is as follows: - Port reports connected event (port status=USB_PORT_STAT_CONNECTION). - Event handler debounces port and resets it by calling hub_port_reset(). - hub_port_reset() calls hub_port_wait_reset() to wait for the reset to complete. - The reset completes, but USB_PORT_STAT_CONNECTION is not immediately set in the port status register. - hub_port_wait_reset() returns -ENOTCONN. - Port initialization sequence is aborted. - A few milliseconds later, the port again reports a connected event, and the sequence repeats. This continues either forever or, randomly, stops if the connection is already re-established when the port status is read. It results in a high rate of udev events. This in turn destabilizes userspace since the above sequence holds the device mutex pretty much continuously and prevents userspace from actually reading the device status. To prevent the problem from happening, let's wait for the connection to be re-established after a port reset. If the device was actually disconnected, the code will still return an error, but it will do so only after the long reset timeout. Cc: Douglas Anderson Signed-off-by: Guenter Roeck Acked-by: Alan Stern Signed-off-by: Sumit Semwal Signed-off-by: Willy Tarreau

USB: fix problems with duplicate endpoint addresses

2017-06-17T14:06:23+00:00

commit 0a8fd1346254974c3a852338508e4a4cddbb35f1 upstream. When checking a new device's descriptors, the USB core does not check for duplicate endpoint addresses. This can cause a problem when the sysfs files for those endpoints are created; trying to create multiple files with the same name will provoke a WARNING: WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0 sysfs: cannot create duplicate filename '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05' Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510 ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] panic+0x1cb/0x3a9 kernel/panic.c:179 [] __warn+0x1c4/0x1e0 kernel/panic.c:542 [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565 [] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30 [] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59 [< inline >] create_dir lib/kobject.c:71 [] kobject_add_internal+0x227/0xa60 lib/kobject.c:229 [< inline >] kobject_add_varg lib/kobject.c:366 [] kobject_add+0x139/0x220 lib/kobject.c:411 [] device_add+0x353/0x1660 drivers/base/core.c:1088 [] device_register+0x1d/0x20 drivers/base/core.c:1206 [] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195 [] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030 [] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937 [] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172 [] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263 This patch prevents the problem by checking for duplicate endpoint addresses during enumeration and skipping any duplicates. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Jiri Slaby Signed-off-by: Willy Tarreau

drivers: usb: core: hub: fix maybe-uninitialized warning

2017-04-13T10:32:12+00:00

drivers/usb/core/hub.c: In function 'usb_port_resume': drivers/usb/core/hub.c:3451:11: warning: 'portstatus' may be used uninitialized in this function [-Wmaybe-uninitialized] status = check_port_resume_type(udev, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ hub, port1, status, portchange, portstatus); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/core/hub.c:3451:11: warning: 'portchange' may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by: Nathan Chancellor

USB: change bInterval default to 10 ms

2017-04-11T08:58:05+00:00

commit 08c5cd37480f59ea39682f4585d92269be6b1424 upstream. 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 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

USB: fix typo in wMaxPacketSize validation

2017-04-11T08:58:03+00:00

commit 6c73358c83ce870c0cf32413e5cadb3b9a39c606 upstream. 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") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau