user/sven/linux.git, branch v5.4.110

Linux 5.4.110

2021-04-07T12:47:45Z

Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Hulk Robot Link: https://lore.kernel.org/r/20210405085024.703004126@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

drivers: video: fbcon: fix NULL dereference in fbcon_cursor()

2021-04-07T12:47:44Z

commit 01faae5193d6190b7b3aa93dae43f514e866d652 upstream. add null-check on function pointer before dereference on ops->cursor Reported-by: syzbot+b67aaae8d3a927f68d20@syzkaller.appspotmail.com Cc: stable Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210312081421.452405-1-ducheng2@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: rtl8192e: Change state information from u16 to u8

2021-04-07T12:47:44Z

commit e78836ae76d20f38eed8c8c67f21db97529949da upstream. The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes. The "CcxRmState" field is fed only 2 bytes of data using memcpy(): (In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2) With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data. Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2); The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized. This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number. rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07; network->MBssidMask is also of type u8 and not u16. Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values. NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: rtl8192e: Fix incorrect source in memcpy()

2021-04-07T12:47:44Z

commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream. The variable "info_element" is of the following type: struct rtllib_info_element *info_element defined in drivers/staging/rtl8192e/rtllib.h: struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed; The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState". Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)). This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]". NOTE: The faulty line of code came from the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: dwc2: Prevent core suspend when port connection flag is 0

2021-04-07T12:47:44Z

commit 93f672804bf2d7a49ef3fd96827ea6290ca1841e upstream. In host mode port connection status flag is "0" when loading the driver. After loading the driver system asserts suspend which is handled by "_dwc2_hcd_suspend()" function. Before the system suspend the port connection status is "0". As result need to check the "port_connect_status" if it is "0", then skipping entering to suspend. Cc: # 5.2 Fixes: 6f6d70597c15 ("usb: dwc2: bus suspend/resume for hosts with DWC2_POWER_DOWN_PARAM_NONE") Signed-off-by: Artur Petrosyan Link: https://lore.kernel.org/r/20210326102510.BDEDEA005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman

usb: dwc2: Fix HPRT0.PrtSusp bit setting for HiKey 960 board.

2021-04-07T12:47:44Z

commit 5e3bbae8ee3d677a0aa2919dc62b5c60ea01ba61 upstream. Increased the waiting timeout for HPRT0.PrtSusp register field to be set, because on HiKey 960 board HPRT0.PrtSusp wasn't generated with the existing timeout. Cc: # 4.18 Fixes: 22bb5cfdf13a ("usb: dwc2: Fix host exit from hibernation flow.") Signed-off-by: Artur Petrosyan Acked-by: Minas Harutyunyan Link: https://lore.kernel.org/r/20210326102447.8F7FEA005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: amd5536udc_pci fix null-ptr-dereference

2021-04-07T12:47:44Z

commit 72035f4954f0bca2d8c47cf31b3629c42116f5b7 upstream. init_dma_pools() calls dma_pool_create(...dev->dev) to create dma pool. however, dev->dev is actually set after calling init_dma_pools(), which effectively makes dma_pool_create(..NULL) and cause crash. To fix this issue, init dma only after dev->dev is set. [ 1.317993] RIP: 0010:dma_pool_create+0x83/0x290 [ 1.323257] Call Trace: [ 1.323390] ? pci_write_config_word+0x27/0x30 [ 1.323626] init_dma_pools+0x41/0x1a0 [snps_udc_core] [ 1.323899] udc_pci_probe+0x202/0x2b1 [amd5536udc_pci] Fixes: 7c51247a1f62 (usb: gadget: udc: Provide correct arguments for 'dma_pool_create') Cc: stable Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210317230400.357756-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: fix use-after-free after probe failure

2021-04-07T12:47:44Z

commit 4e49bf376c0451ad2eae2592e093659cde12be9a upstream. If tty-device registration fails the driver would fail to release the data interface. When the device is later disconnected, the disconnect callback would still be called for the data interface and would go about releasing already freed resources. Fixes: c93d81955005 ("usb: cdc-acm: fix error handling in acm_probe()") Cc: stable@vger.kernel.org # 3.9 Cc: Alexey Khoroshilov Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210322155318.9837-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: fix double free on probe failure

2021-04-07T12:47:44Z

commit 7180495cb3d0e2a2860d282a468b4146c21da78f upstream. If tty-device registration fails the driver copy of any Country Selection functional descriptor would end up being freed twice; first explicitly in the error path and then again in the tty-port destructor. Drop the first erroneous free that was left when fixing a tty-port resource leak. Fixes: cae2bc768d17 ("usb: cdc-acm: Decrement tty port's refcount if probe() fail") Cc: stable@vger.kernel.org # 4.19 Cc: Jaejoong Kim Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210322155318.9837-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: downgrade message to debug

2021-04-07T12:47:44Z

commit e4c77070ad45fc940af1d7fb1e637c349e848951 upstream. This failure is so common that logging an error here amounts to spamming log files. Reviewed-by: Bruno Thomsen Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20210311130126.15972-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman