- Oct 29, 2020
-
-
Greg Kroah-Hartman authored
Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20201027134902.130312227@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lorenzo Colitti authored
[ Upstream commit 7974ecd7 ] Currently, enabling f_ncm at SuperSpeed Plus speeds results in an oops in config_ep_by_speed because ncm_set_alt passes in NULL ssp_descriptors. Fix this by re-using the SuperSpeed descriptors. This is safe because usb_assign_descriptors calls usb_copy_descriptors. Tested: enabled f_ncm on a dwc3 gadget and 10Gbps link, ran iperf Reviewed-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christian Eggers authored
commit 284f52ac upstream. SPI eeproms are addressed by byte. Signed-off-by:
Christian Eggers <ceggers@arri.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200728092959.24600-1-ceggers@arri.de Signed-off-by:
-
Oliver Neukum authored
commit 37d2a363 upstream. syzbot is reporting hung task at wdm_flush() [1], for there is a circular dependency that wdm_flush() from flip_close() for /dev/cdc-wdm0 forever waits for /dev/raw-gadget to be closed while close() for /dev/raw-gadget cannot be called unless close() for /dev/cdc-wdm0 completes. Tetsuo Handa considered that such circular dependency is an usage error [2] which corresponds to an unresponding broken hardware [3]. But Alan Stern responded that we should be prepared for such hardware [4]. Therefore, this patch changes wdm_flush() to use wait_event_interruptible_timeout() which gives up after 30 seconds, for hardware that remains silent must be ignored. The 30 seconds are coming out of thin air. Changing wait_event() to wait_event_interruptible_timeout() makes error reporting from close() syscall less reliable. To compensate it, this patch also implements wdm_fsync() which does not use timeout. Those who want to be very sure that data has gone out to the device are now advised to call fsync(), with a caveat that fsync() can return -EINVAL when running on older kernels which do not implement wdm_fsync(). This patch also fixes three more problems (listed below) found during exhaustive discussion and testing. Since multiple threads can concurrently call wdm_write()/wdm_flush(), we need to use wake_up_all() whenever clearing WDM_IN_USE in order to make sure that all waiters are woken up. Also, error reporting needs to use fetch-and-clear approach in order not to report same error for multiple times. Since wdm_flush() checks WDM_DISCONNECTING, wdm_write() should as well check WDM_DISCONNECTING. In wdm_flush(), since locks are not held, it is not safe to dereference desc->intf after checking that WDM_DISCONNECTING is not set [5]. Thus, remove dev_err() from wdm_flush(). [1] https://syzkaller.appspot.com/bug?id=e7b761593b23eb50855b9ea31e3be5472b711186 [2] https://lkml.kernel.org/r/27b7545e-8f41-10b8-7c02-e35a08eb1611@i-love.sakura.ne.jp [3] https://lkml.kernel.org/r/79ba410f-e0ef-2465-b94f-6b9a4a82adf5@i-love.sakura.ne.jp [4] https://lkml.kernel.org/r/20200530011040.GB12419@rowland.harvard.edu [5] https://lkml.kernel.org/r/c85331fc-874c-6e46-a77f-0ef1dc075308@i-love.sakura.ne.jp Reported-by:
syzbot <syzbot+854768b99f19e89d7f81@syzkaller.appspotmail.com> Cc: stable <stable@vger.kernel.org> Co-developed-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Oliver Neukum <oneukum@suse.com> Cc: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928141755.3476-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by:
-
Vincent Mailhol authored
commit a4f88430 upstream. The ES58X devices has a CDC ACM interface (used for debug purpose). During probing, the device is thus recognized as USB Modem (CDC ACM), preventing the etas-es58x module to load: usbcore: registered new interface driver etas_es58x usb 1-1.1: new full-speed USB device number 14 using xhci_hcd usb 1-1.1: New USB device found, idVendor=108c, idProduct=0159, bcdDevice= 1.00 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.1: Product: ES581.4 usb 1-1.1: Manufacturer: ETAS GmbH usb 1-1.1: SerialNumber: 2204355 cdc_acm 1-1.1:1.0: No union descriptor, testing for castrated device cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device Thus, these have been added to the ignore list in drivers/usb/class/cdc-acm.c N.B. Future firmware release of the ES58X will remove the CDC-ACM interface. `lsusb -v` of the three devices variant (ES581.4, ES582.1 and ES584.1): Bus 001 Device 011: ID 108c:0159 Robert Bosch GmbH ES581.4 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0159 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES581.4 iSerial 3 2204355 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0035 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 5 Bus Powered Configuration bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 iInterface 4 ACM Control Interface CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 0 CDC ACM: bmCapabilities 0x06 sends break line coding and serial state Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Bus 001 Device 012: ID 108c:0168 Robert Bosch GmbH ES582 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0168 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES582 iSerial 3 0108933 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0043 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Bus 001 Device 013: ID 108c:0169 Robert Bosch GmbH ES584.1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0169 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES584.1 iSerial 3 0100320 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0043 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201002154219.4887-8-mailhol.vincent@wanadoo.fr Signed-off-by:
-
Valentin Vidic authored
[ Upstream commit 3bd57b90 ] Fixes gcc warning: passing argument 1 of 'kfree' makes pointer from integer without a cast Fixes: 3af5f0f5 ("net: korina: fix kfree of rx/tx descriptor array") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Valentin Vidic <vvidic@valentin-vidic.from.hr> Link: https://lore.kernel.org/r/20201018184255.28989-1-vvidic@valentin-vidic.from.hr Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Zekun Shen authored
[ Upstream commit bad60b8d ] The idx in __ath10k_htt_rx_ring_fill_n function lives in consistent dma region writable by the device. Malfunctional or malicious device could manipulate such idx to have a OOB write. Either by htt->rx_ring.netbufs_ring[idx] = skb; or by ath10k_htt_set_paddrs_ring(htt, paddr, idx); The idx can also be negative as it's signed, giving a large memory space to write to. It's possibly exploitable by corruptting a legit pointer with a skb pointer. And then fill skb with payload as rougue object. Part of the log here. Sometimes it appears as UAF when writing to a freed memory by chance. [ 15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0 [ 15.595483] #PF: supervisor write access in kernel mode [ 15.596250] #PF: error_code(0x0002) - not-present page [ 15.597013] PGD 0 P4D 0 [ 15.597395] Oops: 0002 [#1] SMP KASAN PTI [ 15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69 [ 15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core Signed-off-by:
Zekun Shen <bruceshenzk@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com Signed-off-by:
-
Eli Billauer authored
[ Upstream commit fbc29943 ] usb_kill_anchored_urbs() is commonly used to cancel all URBs on an anchor just before releasing resources which the URBs rely on. By doing so, users of this function rely on that no completer callbacks will take place from any URB on the anchor after it returns. However if this function is called in parallel with __usb_hcd_giveback_urb processing a URB on the anchor, the latter may call the completer callback after usb_kill_anchored_urbs() returns. This can lead to a kernel panic due to use after release of memory in interrupt context. The race condition is that __usb_hcd_giveback_urb() first unanchors the URB and then makes the completer callback. Such URB is hence invisible to usb_kill_anchored_urbs(), allowing it to return before the completer has been called, since the anchor's urb_list is empty. Even worse, if the racing completer callback resubmits the URB, it may remain in the system long after usb_kill_anchored_urbs() returns. Hence list_empty(&anchor->urb_list), which is used in the existing while-loop, doesn't reliably ensure that all URBs of the anchor are gone. A similar problem exists with usb_poison_anchored_urbs() and usb_scuttle_anchored_urbs(). This patch adds an external do-while loop, which ensures that all URBs are indeed handled before these three functions return. This change has no effect at all unless the race condition occurs, in which case the loop will busy-wait until the racing completer callback has finished. This is a rare condition, so the CPU waste of this spinning is negligible. The additional do-while loop relies on usb_anchor_check_wakeup(), which returns true iff the anchor list is empty, and there is no __usb_hcd_giveback_urb() in the system that is in the middle of the unanchor-before-complete phase. The @suspend_wakeups member of struct usb_anchor is used for this purpose, which was introduced to solve another problem which the same race condition causes, in commit 6ec4147e ("usb-anchor: Delay usb_wait_anchor_empty_timeout wake up till completion is done"). The surely_empty variable is necessary, because usb_anchor_check_wakeup() must be called with the lock held to prevent races. However the spinlock must be released and reacquired if the outer loop spins with an empty URB list while waiting for the unanchor-before-complete passage to finish: The completer callback may very well attempt to take the very same lock. To summarize, using usb_anchor_check_wakeup() means that the patched functions can return only when the anchor's list is empty, and there is no invisible URB being processed. Since the inner while loop finishes on the empty list condition, the new do-while loop will terminate as well, except for when the said race condition occurs. Signed-off-by:
Eli Billauer <eli.billauer@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200731054650.30644-1-eli.billauer@gmail.com Signed-off-by:
-
Wang Yufen authored
[ Upstream commit 6c151410 ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Signed-off-by:
-
Jan Kara authored
[ Upstream commit e9d4709f ] When a usrjquota or grpjquota mount option is used multiple times, we will leak memory allocated for the file name. Make sure the last setting is used and all the previous ones are properly freed. Reported-by:
<syzbot+c9e294bbe0333a6b7640@syzkaller.appspotmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Peilin Ye authored
[ Upstream commit c5a8a849 ] do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is zero. Fix it. Reported-by:
<syzbot+23b5f9e7caf61d9a3898@syzkaller.appspotmail.com> Link: https://syzkaller.appspot.com/bug?id=46ebfb92a8a812621a001ef04d90dfa459520fe2 Suggested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Tong Zhang authored
[ Upstream commit db332356 ] ipwireless_send_packet() can only return 0 on success and -ENOMEM on error, the caller should check non zero for error condition Signed-off-by:
Tong Zhang <ztong0001@gmail.com> Acked-by:
David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20200821161942.36589-1-ztong0001@gmail.com Signed-off-by:
-
Doug Horn authored
[ Upstream commit e219688f ] If a response to virtio_gpu_cmd_get_capset_info takes longer than five seconds to return, the callback will access freed kernel memory in vg->capsets. Signed-off-by:
Doug Horn <doughorn@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansingh@chromium.org Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Chris Chiu authored
[ Upstream commit 86279456 ] Free the skb if usb_submit_urb fails on rx_urb. And free the urb no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb. Signed-off-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
-
Keita Suzuki authored
[ Upstream commit f4443293 ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be freed in the caller function. Fix this by calling wlc_phy_detach_lcnphy in the error handler of wlc_phy_txpwr_srom_read_lcnphy before returning. Signed-off-by:
Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by:
-
Jing Xiangfeng authored
[ Upstream commit 5e48a084 ] Fix to return error code PTR_ERR() from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com Acked-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Abhishek Pandit-Subedi authored
[ Upstream commit 20ae4089 ] Since l2cap_sock_teardown_cb doesn't acquire the channel lock before setting the socket as zapped, it could potentially race with l2cap_sock_release which frees the socket. Thus, wait until the cleanup is complete before marking the socket as zapped. This race was reproduced on a JBL GO speaker after the remote device rejected L2CAP connection due to resource unavailability. Here is a dmesg log with debug logs from a repro of this bug: [ 3465.424086] Bluetooth: hci_core.c:hci_acldata_packet() hci0 len 16 handle 0x0003 flags 0x0002 [ 3465.424090] Bluetooth: hci_conn.c:hci_conn_enter_active_mode() hcon 00000000cfedd07d mode 0 [ 3465.424094] Bluetooth: l2cap_core.c:l2cap_recv_acldata() conn 000000007eae8952 len 16 flags 0x2 [ 3465.424098] Bluetooth: l2cap_core.c:l2cap_recv_frame() len 12, cid 0x0001 [ 3465.424102] Bluetooth: l2cap_core.c:l2cap_raw_recv() conn 000000007eae8952 [ 3465.424175] Bluetooth: l2cap_core.c:l2cap_sig_channel() code 0x03 len 8 id 0x0c [ 3465.424180] Bluetooth: l2cap_core.c:l2cap_connect_create_rsp() dcid 0x0045 scid 0x0000 result 0x02 status 0x00 [ 3465.424189] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 4 [ 3465.424196] Bluetooth: l2cap_core.c:l2cap_chan_del() chan 000000006acf9bff, conn 000000007eae8952, err 111, state BT_CONNECT [ 3465.424203] Bluetooth: l2cap_sock.c:l2cap_sock_teardown_cb() chan 000000006acf9bff state BT_CONNECT [ 3465.424221] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 3 [ 3465.424226] Bluetooth: hci_core.h:hci_conn_drop() hcon 00000000cfedd07d orig refcnt 6 [ 3465.424234] BUG: spinlock bad magic on CPU#2, kworker/u17:0/159 [ 3465.425626] Bluetooth: hci_sock.c:hci_sock_sendmsg() sock 000000002bb0cb64 sk 00000000a7964053 [ 3465.430330] lock: 0xffffff804410aac0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 3465.430332] Causing a watchdog bite! Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reported-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Reviewed-by:
Manish Mandlik <mmandlik@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Hamish Martin authored
[ Upstream commit b77d2a0a ] Some integrated OHCI controller hubs do not expose all ports of the hub to pins on the SoC. In some cases the unconnected ports generate spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC contains a nominally 3 port hub but only the first port is wired. Default behaviour for ohci-platform driver is to use global over-current protection mode (AKA "ganged"). This leads to the spurious over-current events affecting all ports in the hub. We now alter the default to use per-port over-current protection. This patch results in the following configuration changes depending on quirks: - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up for ganged power switching and no over-current protection. - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching remains at none, while over-current protection is now guaranteed to be set to per-port rather than the previous behaviour where it was either none or global over-current protection depending on the value at function entry. Suggested-by:
Hamish Martin <hamish.martin@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200910212512.16670-1-hamish.martin@alliedtelesis.co.nz Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 2a6ca4ba ] There's an overflow bug in the realtime allocator. If the rt volume is large enough to handle a single allocation request that is larger than the maximum bmap extent length and the rt bitmap ends exactly on a bitmap block boundary, it's possible that the near allocator will try to check the freeness of a range that extends past the end of the bitmap. This fails with a corruption error and shuts down the fs. Therefore, constrain maxlen so that the range scan cannot run off the end of the rt bitmap. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Eric Biggers authored
[ Upstream commit 8859bf2b ] unlock_new_inode() is only meant to be called after a new inode has already been inserted into the hash table. But reiserfs_new_inode() can call it even before it has inserted the inode, triggering the WARNING in unlock_new_inode(). Fix this by only calling unlock_new_inode() if the inode has the I_NEW flag set, indicating that it's in the table. This addresses the syzbot report "WARNING in unlock_new_inode" (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). Link: https://lore.kernel.org/r/20200628070057.820213-1-ebiggers@kernel.org Reported-by:
<syzbot+187510916eb6a14598f7@syzkaller.appspotmail.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Keita Suzuki authored
[ Upstream commit bc28369c ] When mfd_add_devices() fail, pcr->slots should also be freed. However, the current implementation does not free the member, leading to a memory leak. Fix this by adding a new goto label that frees pcr->slots. Signed-off-by:
-
Brooke Basile authored
[ Upstream commit 03fb92a4 ] Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor systems create a race condition in which usb_kill_anchored_urbs() deallocates the URB before the completer callback is called in usb_kill_urb(), resulting in a use-after-free. To fix this, add proper lock protection to usb_kill_urb() calls that can possibly run concurrently with usb_kill_anchored_urbs(). Reported-by:
<syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com> Link: https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf Signed-off-by:
Brooke Basile <brookebasile@gmail.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 960c7339 ] Handle broken union functional descriptors where the master-interface doesn't exist or where its class is of neither Communication or Data type (as required by the specification) by falling back to "combined-interface" probing. Note that this still allows for handling union descriptors with switched interfaces. This specifically makes the Whistler radio scanners TRX series devices work with the driver without adding further quirks to the device-id table. Reported-by:
Daniel Caujolle-Bert <f1rmb.daniel@gmail.com> Tested-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200921135951.24045-3-johan@kernel.org Signed-off-by:
-
Jan Kara authored
[ Upstream commit 044e2e26 ] When we fail to read inode, some data accessed in udf_evict_inode() may be uninitialized. Move the accesses to !is_bad_inode() branch. Reported-by:
<syzbot+91f02b28f9bb5f5f1341@syzkaller.appspotmail.com> Signed-off-by:
-
Jan Kara authored
[ Upstream commit 44ac6b82 ] Although UDF standard allows it, we don't support sparing table larger than a single block. Check it during mount so that we don't try to access memory beyond end of buffer. Reported-by:
<syzbot+9991561e714f597095da@syzkaller.appspotmail.com> Signed-off-by:
-
Zqiang authored
[ Upstream commit e8d5f92b ] Fix this by increase object reference count. BUG: KASAN: use-after-free in __lock_acquire+0x3fd4/0x4180 kernel/locking/lockdep.c:3831 Read of size 8 at addr ffff8880683b0018 by task syz-executor.0/3377 CPU: 1 PID: 3377 Comm: syz-executor.0 Not tainted 5.6.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x131/0x1b0 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 __lock_acquire+0x3fd4/0x4180 kernel/locking/lockdep.c:3831 lock_acquire+0x127/0x350 kernel/locking/lockdep.c:4488 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 printer_ioctl+0x4a/0x110 drivers/usb/gadget/function/f_printer.c:723 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl+0xfb/0x130 fs/ioctl.c:763 __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl fs/ioctl.c:770 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4531a9 Code: ed 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fd14ad72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 00000000004531a9 RDX: fffffffffffffff9 RSI: 000000000000009e RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004bbd61 R13: 00000000004d0a98 R14: 00007fd14ad736d4 R15: 00000000ffffffff Allocated by task 2393: save_stack+0x21/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc.constprop.3+0xa7/0xd0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0xfa/0x2d0 mm/slub.c:2813 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] gprinter_alloc+0xa1/0x870 drivers/usb/gadget/function/f_printer.c:1416 usb_get_function+0x58/0xc0 drivers/usb/gadget/functions.c:61 config_usb_cfg_link+0x1ed/0x3e0 drivers/usb/gadget/configfs.c:444 configfs_symlink+0x527/0x11d0 fs/configfs/symlink.c:202 vfs_symlink+0x33d/0x5b0 fs/namei.c:4201 do_symlinkat+0x11b/0x1d0 fs/namei.c:4228 __do_sys_symlinkat fs/namei.c:4242 [inline] __se_sys_symlinkat fs/namei.c:4239 [inline] __x64_sys_symlinkat+0x73/0xb0 fs/namei.c:4239 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 3368: save_stack+0x21/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x135/0x190 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 slab_free_hook mm/slub.c:1444 [inline] slab_free_freelist_hook mm/slub.c:1477 [inline] slab_free mm/slub.c:3034 [inline] kfree+0xf7/0x410 mm/slub.c:3995 gprinter_free+0x49/0xd0 drivers/usb/gadget/function/f_printer.c:1353 usb_put_function+0x38/0x50 drivers/usb/gadget/functions.c:87 config_usb_cfg_unlink+0x2db/0x3b0 drivers/usb/gadget/configfs.c:485 configfs_unlink+0x3b9/0x7f0 fs/configfs/symlink.c:250 vfs_unlink+0x287/0x570 fs/namei.c:4073 do_unlinkat+0x4f9/0x620 fs/namei.c:4137 __do_sys_unlink fs/namei.c:4184 [inline] __se_sys_unlink fs/namei.c:4182 [inline] __x64_sys_unlink+0x42/0x50 fs/namei.c:4182 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880683b0000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 24 bytes inside of 1024-byte region [ffff8880683b0000, ffff8880683b0400) The buggy address belongs to the page: page:ffffea0001a0ec00 refcount:1 mapcount:0 mapping:ffff88806c00e300 index:0xffff8880683b1800 compound_mapcount: 0 flags: 0x100000000010200(slab|head) raw: 0100000000010200 0000000000000000 0000000600000001 ffff88806c00e300 raw: ffff8880683b1800 000000008010000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Reported-by:
Kyungtae Kim <kt0755@gmail.com> Signed-off-by:
Zqiang <qiang.zhang@windriver.com> Signed-off-by:
-
Sherry Sun authored
[ Upstream commit cc1a2679 ] Since struct _mic_vring_info and vring are allocated together and follow vring, if the vring_size() is not four bytes aligned, which will cause the start address of struct _mic_vring_info is not four byte aligned. For example, when vring entries is 128, the vring_size() will be 5126 bytes. The _mic_vring_info struct layout in ddr looks like: 0x90002400: 00000000 00390000 EE010000 0000C0FF Here 0x39 is the avail_idx member, and 0xC0FFEE01 is the magic member. When EP use ioread32(magic) to reads the magic in RC's share memory, it will cause kernel panic on ARM64 platform due to the cross-byte io read. Here read magic in user space use le32toh(vr0->info->magic) will meet the same issue. So add round_up(x,4) for vring_size, then the struct _mic_vring_info will store in this way: 0x90002400: 00000000 00000000 00000039 C0FFEE01 Which will avoid kernel panic when read magic in struct _mic_vring_info. Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929091106.24624-4-sherry.sun@nxp.com Signed-off-by:
-
Sherry Sun authored
[ Upstream commit 675f0ad4 ] Read and write io memory should address align on ARCH ARM. Change to use memcpy_toio to avoid kernel panic caused by the address un-align issue. Signed-off-by:
-
Roman Bolshakov authored
[ Upstream commit 7010645b ] trace-cmd report doesn't show events from target subsystem because scsi_command_size() leaks through event format string: [target:target_sequencer_start] function scsi_command_size not defined [target:target_cmd_complete] function scsi_command_size not defined Addition of scsi_command_size() to plugin_scsi.c in trace-cmd doesn't help because an expression is used inside TP_printk(). trace-cmd event parser doesn't understand minus sign inside [ ]: Error: expected ']' but read '-' Rather than duplicating kernel code in plugin_scsi.c, provide a dedicated field for CONTROL byte. Link: https://lore.kernel.org/r/20200929125957.83069-1-r.bolshakov@yadro.com Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
Jing Xiangfeng authored
[ Upstream commit 055f15ab ] Return PTR_ERR() from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200910123848.93649-1-jingxiangfeng@huawei.com Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 428805c0 ] get_gendisk grabs a reference on the disk and file operation, so this code will leak both of them while having absolutely no use for the gendisk itself. This effectively reverts commit 2df83fa4 ("PM / Hibernate: Use get_gendisk to verify partition if resume_file is integer format") Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Rustam Kovhaev authored
[ Upstream commit 4f8c9402 ] Number of bytes allocated for mft record should be equal to the mft record size stored in ntfs superblock as reported by syzbot, userspace might trigger out-of-bounds read by dereferencing ctx->attr in ntfs_attr_find() Reported-by:
<syzbot+aed06913f36eff9b544e@syzkaller.appspotmail.com> Signed-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
Anton Altaparmakov <anton@tuxera.com> Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e Link: https://lkml.kernel.org/r/20200824022804.226242-1-rkovhaev@gmail.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alexander Aring authored
[ Upstream commit 3d2825c8 ] This patch fixes the following memory detected by kmemleak and umount gfs2 filesystem which removed the last lockspace: unreferenced object 0xffff9264f482f600 (size 192): comm "dlm_controld", pid 325, jiffies 4294690276 (age 48.136s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 6e 6f 64 65 73 00 00 00 ........nodes... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000060481d7>] make_space+0x41/0x130 [<000000008d905d46>] configfs_mkdir+0x1a2/0x5f0 [<00000000729502cf>] vfs_mkdir+0x155/0x210 [<000000000369bcf1>] do_mkdirat+0x6d/0x110 [<00000000cc478a33>] do_syscall_64+0x33/0x40 [<00000000ce9ccf01>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 The patch just remembers the "nodes" entry pointer in space as I think it's created as subdirectory when parent "spaces" is created. In function drop_space() we will lost the pointer reference to nds because configfs_remove_default_groups(). However as this subdirectory is always available when "spaces" exists it will just be freed when "spaces" will be freed. Signed-off-by:
Alexander Aring <aahringo@redhat.com> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 15a36aae ] As reported by smatch: drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type? On a 64-bits Kernel, the shift might be bigger than 32 bits. In real, this should never happen, but let's shut up the warning. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Pali Rohár authored
[ Upstream commit 8ebe2607 ] Before parsing CISTPL_VERS_1 structure check that its size is at least two bytes to prevent buffer overflow. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200727133837.19086-2-pali@kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Adam Goode authored
[ Upstream commit 8a652a17 ] bFrameIndex and bFormatIndex can be negotiated by the camera during probing, resulting in the camera choosing a different format than expected. v4l2 can already accommodate such changes, but the code was not updating the proper fields. Without such a change, v4l2 would potentially interpret the payload incorrectly, causing corrupted output. This was happening on the Elgato HD60 S+, which currently always renegotiates to format 1. As an aside, the Elgato firmware is buggy and should not be renegotating, but it is still a valid thing for the camera to do. Both macOS and Windows will properly probe and read uncorrupted images from this camera. With this change, both qv4l2 and chromium can now read uncorrupted video from the Elgato HD60 S+. [Add blank lines, remove periods at the of messages] Signed-off-by:
Adam Goode <agoode@google.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Xiaolong Huang authored
[ Upstream commit 7b817585 ] In bttv_probe if some functions such as pci_enable_device, pci_set_dma_mask and request_mem_region fails the allocated memory for btv should be released. Signed-off-by:
Xiaolong Huang <butterflyhuangxx@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit dbd2f2dc ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit d912a1d9 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit dafa3605 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Also, call pm_runtime_disable() when pm_runtime_get_sync() returns an error code. Signed-off-by:
Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by:
-
