linux/drivers/usb/core, branch v5.4

USB: Skip endpoints with 0 maxpacket length

2019-10-28T16:46:22Z

Endpoints with a maxpacket length of 0 are probably useless. They can't transfer any data, and it's not at all unlikely that an HCD will crash or hang when trying to handle an URB for such an endpoint. Currently the USB core does not check for endpoints having a maxpacket value of 0. This patch adds a check, printing a warning and skipping over any endpoints it catches. Now, the USB spec does not rule out endpoints having maxpacket = 0. But since they wouldn't have any practical use, there doesn't seem to be any good reason for us to accept them. Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman

USB: usbcore: Fix slab-out-of-bounds bug during device reset

2019-09-04T16:24:00Z

The syzbot fuzzer provoked a slab-out-of-bounds error in the USB core: BUG: KASAN: slab-out-of-bounds in memcmp+0xa6/0xb0 lib/string.c:904 Read of size 1 at addr ffff8881d175bed6 by task kworker/0:3/2746 CPU: 0 PID: 2746 Comm: kworker/0:3 Not tainted 5.3.0-rc5+ #28 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 memcmp+0xa6/0xb0 lib/string.c:904 memcmp include/linux/string.h:400 [inline] descriptors_changed drivers/usb/core/hub.c:5579 [inline] usb_reset_and_verify_device+0x564/0x1300 drivers/usb/core/hub.c:5729 usb_reset_device+0x4c1/0x920 drivers/usb/core/hub.c:5898 rt2x00usb_probe+0x53/0x7af drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:806 The error occurs when the descriptors_changed() routine (called during a device reset) attempts to compare the old and new BOS and capability descriptors. The length it uses for the comparison is the wTotalLength value stored in BOS descriptor, but this value is not necessarily the same as the length actually allocated for the descriptors. If it is larger the routine will call memcmp() with a length that is too big, thus reading beyond the end of the allocated region and leading to this fault. The kernel reads the BOS descriptor twice: first to get the total length of all the capability descriptors, and second to read it along with all those other descriptors. A malicious (or very faulty) device may send different values for the BOS descriptor fields each time. The memory area will be allocated using the wTotalLength value read the first time, but stored within it will be the value read the second time. To prevent this possibility from causing any errors, this patch modifies the BOS descriptor after it has been read the second time: It sets the wTotalLength field to the actual length of the descriptors that were read in and validated. Then the memcpy() call, or any other code using these descriptors, will be able to rely on wTotalLength being valid. Reported-and-tested-by: syzbot+35f4d916c623118d576e@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1909041154260.1722-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman

Merge generic_lookup_helpers into usb-next

2019-09-03T15:11:07Z

The lookup helpers are needed here. Signed-off-by: Greg Kroah-Hartman

usb: core: phy: add support for PHY calibration

2019-09-03T13:54:55Z

Some PHYs (for example Exynos5 USB3.0 DRD PHY) require calibration to be done after every USB HCD reset. Generic PHY framework has been already extended with phy_calibrate() function in commit 36914111e682 ("drivers: phy: add calibrate method"). This patch adds support for it to generic PHY handling code in USB HCD core. Signed-off-by: Marek Szyprowski Tested-by: Anand Moon Tested-by: Jochen Sprickerhof Link: https://lore.kernel.org/r/20190829053028.32438-2-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman

usb: remove commented out dma wrappers

2019-09-03T13:26:12Z

These wrappers have never seen use and have been commented out for a long time. Remove them for good. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190903084615.19161-6-hch@lst.de Signed-off-by: Greg Kroah-Hartman

usb: remove a stale comment in hcd_alloc_coherent

2019-09-03T13:26:11Z

Now that we have the local memory pool implemented there is no need to use dma_declare_coherent_memory. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190903084615.19161-5-hch@lst.de Signed-off-by: Greg Kroah-Hartman

Merge 5.3-rc7 into usb-next

2019-09-02T17:31:18Z

We need the usb fixes in here for testing Signed-off-by: Greg Kroah-Hartman

usb: hcd: use managed device resources

2019-08-28T20:48:37Z

Using managed device resources in usb_hcd_pci_probe() allows devm usage for resource subranges, such as the mmio resource for the platform device created to control host/device mode mux, which is a xhci extended capability, and sits inside the xhci mmio region. If managed device resources are not used then "parent" resource is released before subrange at driver removal as .remove callback is called before the devres list of resources for this device is walked and released. This has been observed with the xhci extended capability driver causing a use-after-free which is now fixed. An additional nice benefit is that error handling on driver initialisation is simplified much. Signed-off-by: Carsten Schmid Tested-by: Carsten Schmid Reviewed-by: Mathias Nyman Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling") Cc: # v4.19+ Link: https://lore.kernel.org/r/1566569488679.31808@mentor.com Signed-off-by: Greg Kroah-Hartman

usb: add a HCD_DMA flag instead of guestimating DMA capabilities

2019-08-21T17:03:35Z

The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman

usb: usbfs: only account once for mmap()'ed usb memory usage

2019-08-21T16:57:36Z

Memory usage for USB memory allocated via mmap() is already accounted for at mmap() time; no need to account for it again at submiturb time. Signed-off-by: Gavin Li Acked-by: Alan Stern Link: https://lore.kernel.org/r/20190814212924.10381-1-gavinli@thegavinli.com Signed-off-by: Greg Kroah-Hartman