kernel/linux.git/drivers/usb/core/devio.c, branch v5.15.7

USB: core: Fix incorrect pipe calculation in do_proc_control()

2021-07-12T18:59:40+00:00

When the user submits a control URB via usbfs, the user supplies the bRequestType value and the kernel uses it to compute the pipe value. However, do_proc_control() performs this computation incorrectly in the case where the bRequestType direction bit is set to USB_DIR_IN and the URB's transfer length is 0: The pipe's direction is also set to IN but it should be OUT, which is the direction the actual transfer will use regardless of bRequestType. Commit 5cc59c418fde ("USB: core: WARN if pipe direction != setup packet direction") added a check to compare the direction bit in the pipe value to a control URB's actual direction and to WARN if they are different. This can be triggered by the incorrect computation mentioned above, as found by syzbot. This patch fixes the computation, thus avoiding the WARNing. Reported-and-tested-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210712185436.GB326369@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

Merge 5.13-rc4 into usb-next

2021-05-31T07:50:26+00:00

We need the usb/thunderbolt fixes in here as well. Signed-off-by: Greg Kroah-Hartman

USB: usbfs: remove double evaluation of usb_sndctrlpipe()

2021-05-24T13:27:14+00:00

usb_sndctrlpipe() is evaluated in do_proc_control(), saved in a variable, then evaluated again. Use the saved variable instead, to match the use of usb_rcvctrlpipe(). Acked-by: Alan Stern Signed-off-by: Geoffrey D. Bennett Link: https://lore.kernel.org/r/20210521174027.GA116484@m.b4.vu Signed-off-by: Greg Kroah-Hartman

USB: usbfs: Don't WARN about excessively large memory allocations

2021-05-21T12:24:46+00:00

Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. CC: Andrew Morton CC: Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

USB: core: Change %pK for __user pointers to %px

2020-11-20T15:36:31+00:00

Commit 2f964780c03b ("USB: core: replace %p with %pK") used the %pK format specifier for a bunch of __user pointers. But as the 'K' in the specifier indicates, it is meant for kernel pointers. The reason for the %pK specifier is to avoid leaks of kernel addresses, but when the pointer is to an address in userspace the security implications are minimal. In particular, no kernel information is leaked. This patch changes the __user %pK specifiers (used in a bunch of debugging output lines) to %px, which will always print the actual address with no mangling. (Notably, there is no printk format specifier particularly intended for __user pointers.) Fixes: 2f964780c03b ("USB: core: replace %p with %pK") CC: Vamsi Krishna Samavedam CC: Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20201119170228.GB576844@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

usb: usbfs: stop using compat_alloc_user_space

2020-07-22T11:13:22+00:00

Just switch the low-level routines to take kernel structures, and do the conversion from the compat to the native structure on that. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200722073655.220011-1-hch@lst.de Signed-off-by: Greg Kroah-Hartman

Merge branch 'uaccess.access_ok' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2020-06-01T23:09:43+00:00

Pull uaccess/access_ok updates from Al Viro: "Removals of trivially pointless access_ok() calls. Note: the fiemap stuff was removed from the series, since they are duplicates with part of ext4 series carried in Ted's tree" * 'uaccess.access_ok' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: vmci_host: get rid of pointless access_ok() hfi1: get rid of pointless access_ok() usb: get rid of pointless access_ok() calls lpfc_debugfs: get rid of pointless access_ok() efi_test: get rid of pointless access_ok() drm_read(): get rid of pointless access_ok() via-pmu: don't bother with access_ok() drivers/crypto/ccp/sev-dev.c: get rid of pointless access_ok() omapfb: get rid of pointless access_ok() calls amifb: get rid of pointless access_ok() calls drivers/fpga/dfl-afu-dma-region.c: get rid of pointless access_ok() drivers/fpga/dfl-fme-pr.c: get rid of pointless access_ok() cm4000_cs.c cmm_ioctl(): get rid of pointless access_ok() nvram: drop useless access_ok() n_hdlc_tty_read(): remove pointless access_ok() tomoyo_write_control(): get rid of pointless access_ok() btrfs_ioctl_send(): don't bother with access_ok() fat_dir_ioctl(): hadn't needed that access_ok() for more than a decade... dlmfs_file_write(): get rid of pointless access_ok()

usb: get rid of pointless access_ok() calls

2020-05-29T15:05:58+00:00

in all affected cases addresses are passed only to copy_from()_user or copy_to_user(). Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro

USB: usbfs: fix mmap dma mismatch

2020-05-14T16:39:57+00:00

In commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute mismatch") we switched from always calling remap_pfn_range() to call dma_mmap_coherent() to handle issues with systems with non-coherent USB host controller drivers. Unfortunatly, as syzbot quickly told us, not all the world is host controllers with DMA support, so we need to check what host controller we are attempting to talk to before doing this type of allocation. Thanks to Christoph for the quick idea of how to fix this. Fixes: 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute mismatch") Cc: Christoph Hellwig Cc: Hillf Danton Cc: Thomas Gleixner Cc: Jeremy Linton Cc: stable Reported-by: syzbot+353be47c9ce21b68b7ed@syzkaller.appspotmail.com Reviewed-by: Jeremy Linton Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200514112711.1858252-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

usb: usbfs: correct kernel->user page attribute mismatch

2020-05-05T11:06:46+00:00

On some architectures (e.g. arm64) requests for IO coherent memory may use non-cachable attributes if the relevant device isn't cache coherent. If these pages are then remapped into userspace as cacheable, they may not be coherent with the non-cacheable mappings. In particular this happens with libusb, when it attempts to create zero-copy buffers for use by rtl-sdr (https://github.com/osmocom/rtl-sdr/). On low end arm devices with non-coherent USB ports, the application will be unexpectedly killed, while continuing to work fine on arm machines with coherent USB controllers. This bug has been discovered/reported a few times over the last few years. In the case of rtl-sdr a compile time option to enable/disable zero copy was implemented to work around it. Rather than relaying on application specific workarounds, dma_mmap_coherent() can be used instead of remap_pfn_range(). The page cache/etc attributes will then be correctly set in userspace to match the kernel mapping. Signed-off-by: Jeremy Linton Cc: stable Link: https://lore.kernel.org/r/20200504201348.1183246-1-jeremy.linton@arm.com Signed-off-by: Greg Kroah-Hartman