user/sven/linux.git, branch v4.14.5

Linux 4.14.5

2017-12-10T12:40:45Z

locking/refcounts: Do not force refcount_t usage as GPL-only export

2017-12-10T12:40:45Z

commit b562c171cf011d297059bd0265742eb5fab0ad2f upstream. The refcount_t protection on x86 was not intended to use the stricter GPL export. This adjusts the linkage again to avoid a regression in the availability of the refcount API. Reported-by: Dave Airlie Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount overflow protection") Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds Cc: Ivan Kozik Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman

usb: host: fix incorrect updating of offset

2017-12-10T12:40:44Z

commit 1d5a31582ef046d3b233f0da1a68ae26519b2f0a upstream. The variable temp is incorrectly being updated, instead it should be offset otherwise the loop just reads the same capability value and loops forever. Thanks to Alan Stern for pointing out the correct fix to my original fix. Fix also cleans up clang warning: drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp' is never read Fixes: d49d43174400 ("USB: misc ehci updates") Signed-off-by: Colin Ian King Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: usbfs: Filter flags passed in from user space

2017-12-10T12:40:44Z

commit 446f666da9f019ce2ffd03800995487e79a91462 upstream. USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints. Improve sanity checking. Reported-by: Andrey Konovalov Signed-off-by: Oliver Neukum Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: core: Add type-specific length check of BOS descriptors

2017-12-10T12:40:44Z

commit 81cf4a45360f70528f1f64ba018d61cb5767249a upstream. As most of BOS descriptors are longer in length than their header 'struct usb_dev_cap_header', comparing solely with it is not sufficient to avoid out-of-bounds access to BOS descriptors. This patch adds descriptor type specific length check in usb_get_bos_descriptor() to fix the issue. Signed-off-by: Masakazu Mokuno Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix panic in xhci_free_virt_devices_depth_first

2017-12-10T12:40:44Z

commit 80e457699a8dbdd70f2d26911e46f538645c55fc upstream. Check vdev->real_port 0 to avoid panic [ 9.261347] [] xhci_free_virt_devices_depth_first+0x58/0x108 [ 9.261352] [] xhci_mem_cleanup+0x1bc/0x570 [ 9.261355] [] xhci_stop+0x140/0x1c8 [ 9.261365] [] usb_remove_hcd+0xfc/0x1d0 [ 9.261369] [] xhci_plat_remove+0x6c/0xa8 [ 9.261377] [] platform_drv_remove+0x2c/0x70 [ 9.261384] [] __device_release_driver+0x80/0x108 [ 9.261387] [] device_release_driver+0x2c/0x40 [ 9.261392] [] bus_remove_device+0xe0/0x120 [ 9.261396] [] device_del+0x114/0x210 [ 9.261399] [] platform_device_del+0x30/0xa0 [ 9.261403] [] dwc3_otg_work+0x204/0x488 [ 9.261407] [] event_work+0x304/0x5b8 [ 9.261414] [] process_one_work+0x148/0x490 [ 9.261417] [] worker_thread+0x50/0x4a0 [ 9.261421] [] kthread+0xe8/0x100 [ 9.261427] [] ret_from_fork+0x10/0x50 The problem can occur if xhci_plat_remove() is called shortly after xhci_plat_probe(). While xhci_free_virt_devices_depth_first been called before the device has been setup and get real_port initialized. The problem occurred on Hikey960 and was reproduced by Guenter Roeck on Kevin with chromeos-4.4. Fixes: ee8665e28e8d ("xhci: free xhci virtual devices with leaf nodes first") Cc: Guenter Roeck Reviewed-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Fan Ning Signed-off-by: Li Rui Signed-off-by: yangdi Signed-off-by: Yu Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Don't show incorrect WARN message about events for empty rings

2017-12-10T12:40:44Z

commit e4ec40ec4b260efcca15089de4285a0a3411259b upstream. xHC can generate two events for a short transfer if the short TRB and last TRB in the TD are not the same TRB. The driver will handle the TD after the first short event, and remove it from its internal list. Driver then incorrectly prints a warning for the second event: "WARN Event TRB for slot x ep y with no TDs queued" Fix this by not printing a warning if we get a event on a empty list if the previous event was a short event. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: ulpi: fix bus-node lookup

2017-12-10T12:40:44Z

commit 33c309ebc797b908029fd3a0851aefe697e9b598 upstream. Fix bus-node lookup during registration, which ended up searching the whole device tree depth-first starting at the parent (or grand parent) rather than just matching on its children. To make things worse, the parent (or grand-parent) node could end being prematurely freed as well. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Reported-by: Peter Robinson Reported-by: Stephen Boyd Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb: hub: Cycle HUB power when initialization fails

2017-12-10T12:40:44Z

commit 973593a960ddac0f14f0d8877d2d0abe0afda795 upstream. Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device still needs to be configured. To work around this issue, power-cycle the hub's output to issue a sort of "reset" to the device. This makes the device restart its state machine and then the initialization succeeds. This fixes problems where the kernel reports a list of errors like this: usb 1-1.3: device not accepting address 19, error -71 The end result is a non-functioning device. After this patch, the sequence becomes like this: usb 1-1.3: new high-speed USB device number 18 using ci_hdrc usb 1-1.3: device not accepting address 18, error -71 usb 1-1.3: new high-speed USB device number 19 using ci_hdrc usb 1-1.3: device not accepting address 19, error -71 usb 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by: Mike Looijmans Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

staging: ccree: fix leak of import() after init()

2017-12-10T12:40:44Z

commit c5f39d07860c35e5e4c63188139465af790f86ce upstream. crypto_ahash_import() may be called either after crypto_ahash_init() or without such call. Right now we always internally call init() as part of import(), thus leaking memory and mappings if the user has already called init() herself. Fix this by only calling init() internally if the state is not already initialized. Fixes: commit 454527d0d94f ("staging: ccree: fix hash import/export") Signed-off-by: Gilad Ben-Yossef Reviewed-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman