From: Sasha Levin Date: Mon, 25 Jan 2021 03:21:28 +0000 (-0500) Subject: Fixes for 4.19 X-Git-Tag: v4.19.171~30 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=39cd5d626f037030f69e0983a3aa7cf9d8668679;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/can-dev-can_restart-fix-use-after-free-bug.patch b/queue-4.19/can-dev-can_restart-fix-use-after-free-bug.patch new file mode 100644 index 00000000000..c8d86bfe321 --- /dev/null +++ b/queue-4.19/can-dev-can_restart-fix-use-after-free-bug.patch @@ -0,0 +1,46 @@ +From fe58139e78b52ebcb8210c480f9caf9eee665279 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 20 Jan 2021 20:41:35 +0900 +Subject: can: dev: can_restart: fix use after free bug + +From: Vincent Mailhol + +[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ] + +After calling netif_rx_ni(skb), dereferencing skb is unsafe. +Especially, the can_frame cf which aliases skb memory is accessed +after the netif_rx_ni() in: + stats->rx_bytes += cf->len; + +Reordering the lines solves the issue. + +Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") +Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/dev.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c +index f88590074569e..953c6fdc75cc4 100644 +--- a/drivers/net/can/dev.c ++++ b/drivers/net/can/dev.c +@@ -579,11 +579,11 @@ static void can_restart(struct net_device *dev) + } + cf->can_id |= CAN_ERR_RESTARTED; + +- netif_rx_ni(skb); +- + stats->rx_packets++; + stats->rx_bytes += cf->can_dlc; + ++ netif_rx_ni(skb); ++ + restart: + netdev_dbg(dev, "restarted\n"); + priv->can_stats.restarts++; +-- +2.27.0 + diff --git a/queue-4.19/can-peak_usb-fix-use-after-free-bugs.patch b/queue-4.19/can-peak_usb-fix-use-after-free-bugs.patch new file mode 100644 index 00000000000..74770104e23 --- /dev/null +++ b/queue-4.19/can-peak_usb-fix-use-after-free-bugs.patch @@ -0,0 +1,59 @@ +From 0f036b27064620f3e5d0166c0cc2d35670559179 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 20 Jan 2021 20:41:37 +0900 +Subject: can: peak_usb: fix use after free bugs + +From: Vincent Mailhol + +[ Upstream commit 50aca891d7a554db0901b245167cd653d73aaa71 ] + +After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. +Especially, the can_frame cf which aliases skb memory is accessed +after the peak_usb_netif_rx_ni(). + +Reordering the lines solves the issue. + +Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") +Link: https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vincent@wanadoo.fr +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c +index 19600d35aac55..40ac37fe9dcde 100644 +--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c ++++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c +@@ -520,11 +520,11 @@ static int pcan_usb_fd_decode_canmsg(struct pcan_usb_fd_if *usb_if, + else + memcpy(cfd->data, rm->d, cfd->len); + +- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low)); +- + netdev->stats.rx_packets++; + netdev->stats.rx_bytes += cfd->len; + ++ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low)); ++ + return 0; + } + +@@ -586,11 +586,11 @@ static int pcan_usb_fd_decode_status(struct pcan_usb_fd_if *usb_if, + if (!skb) + return -ENOMEM; + +- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low)); +- + netdev->stats.rx_packets++; + netdev->stats.rx_bytes += cf->can_dlc; + ++ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low)); ++ + return 0; + } + +-- +2.27.0 + diff --git a/queue-4.19/can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch b/queue-4.19/can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch new file mode 100644 index 00000000000..b084bbe6bd3 --- /dev/null +++ b/queue-4.19/can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch @@ -0,0 +1,53 @@ +From b95aa40f0564426a862f88d4ac4bc18b804c19a7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 20 Jan 2021 20:41:36 +0900 +Subject: can: vxcan: vxcan_xmit: fix use after free bug + +From: Vincent Mailhol + +[ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ] + +After calling netif_rx_ni(skb), dereferencing skb is unsafe. +Especially, the canfd_frame cfd which aliases skb memory is accessed +after the netif_rx_ni(). + +Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)") +Link: https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vincent@wanadoo.fr +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/vxcan.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c +index ed6828821fbd3..ccd758ba3fb09 100644 +--- a/drivers/net/can/vxcan.c ++++ b/drivers/net/can/vxcan.c +@@ -49,6 +49,7 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev) + struct net_device *peer; + struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct net_device_stats *peerstats, *srcstats = &dev->stats; ++ u8 len; + + if (can_dropped_invalid_skb(dev, skb)) + return NETDEV_TX_OK; +@@ -71,12 +72,13 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev) + skb->dev = peer; + skb->ip_summed = CHECKSUM_UNNECESSARY; + ++ len = cfd->len; + if (netif_rx_ni(skb) == NET_RX_SUCCESS) { + srcstats->tx_packets++; +- srcstats->tx_bytes += cfd->len; ++ srcstats->tx_bytes += len; + peerstats = &peer->stats; + peerstats->rx_packets++; +- peerstats->rx_bytes += cfd->len; ++ peerstats->rx_bytes += len; + } + + out_unlock: +-- +2.27.0 + diff --git a/queue-4.19/i2c-octeon-check-correct-size-of-maximum-recv_len-pa.patch b/queue-4.19/i2c-octeon-check-correct-size-of-maximum-recv_len-pa.patch new file mode 100644 index 00000000000..f934d59e96b --- /dev/null +++ b/queue-4.19/i2c-octeon-check-correct-size-of-maximum-recv_len-pa.patch @@ -0,0 +1,37 @@ +From 526e970c293ee45b3224af85f5cb85644c4a7f2e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 9 Jan 2021 13:43:08 +0100 +Subject: i2c: octeon: check correct size of maximum RECV_LEN packet + +From: Wolfram Sang + +[ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ] + +I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the +SMBus 2.0 specs. No reason to add one to it. + +Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN") +Signed-off-by: Wolfram Sang +Reviewed-by: Robert Richter +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + drivers/i2c/busses/i2c-octeon-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/i2c/busses/i2c-octeon-core.c b/drivers/i2c/busses/i2c-octeon-core.c +index d9607905dc2f1..845eda70b8cab 100644 +--- a/drivers/i2c/busses/i2c-octeon-core.c ++++ b/drivers/i2c/busses/i2c-octeon-core.c +@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int target, + if (result) + return result; + if (recv_len && i == 0) { +- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1) ++ if (data[i] > I2C_SMBUS_BLOCK_MAX) + return -EPROTO; + length += data[i]; + } +-- +2.27.0 + diff --git a/queue-4.19/platform-x86-intel-vbtn-drop-hp-stream-x360-converti.patch b/queue-4.19/platform-x86-intel-vbtn-drop-hp-stream-x360-converti.patch new file mode 100644 index 00000000000..0004439b78f --- /dev/null +++ b/queue-4.19/platform-x86-intel-vbtn-drop-hp-stream-x360-converti.patch @@ -0,0 +1,72 @@ +From d8eef2bebb23109b8b3b709ddbca7dc454e0c9fb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 14 Jan 2021 15:34:32 +0100 +Subject: platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from + allow-list + +From: Hans de Goede + +[ Upstream commit 070222731be52d741e55d8967b1764482b81e54c ] + +THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function: + + Method (VGBS, 0, Serialized) + { + If ((^^PCI0.LPCB.EC0.ROLS == Zero)) + { + VBDS = Zero + } + Else + { + VBDS = Zero + } + + Return (VBDS) /* \_SB_.VGBI.VBDS */ + } + +Which is obviously wrong, because it always returns 0 independent of the +2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver +to initially report SW_TABLET_MODE = 1 to userspace, which is known to +cause problems when the 2-in-1 is actually in laptop mode. + +During earlier testing this turned out to not be a problem because the +2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after +the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state. + +Further testing however has shown that this Notify() soon after the +intel-vbtn driver loads, does not always happen. When the Notify +does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in +a non-working touchpad. + +IOW the tablet-mode reporting is not reliable on this device, so it +should be dropped from the allow-list, fixing the touchpad sometimes +not working. + +Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") +Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/intel-vbtn.c | 6 ------ + 1 file changed, 6 deletions(-) + +diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c +index 36d6e72f50735..f5774372c3871 100644 +--- a/drivers/platform/x86/intel-vbtn.c ++++ b/drivers/platform/x86/intel-vbtn.c +@@ -191,12 +191,6 @@ static const struct dmi_system_id dmi_switches_allow_list[] = { + DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"), + }, + }, +- { +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), +- DMI_MATCH(DMI_PRODUCT_NAME, "HP Stream x360 Convertible PC 11"), +- }, +- }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), +-- +2.27.0 + diff --git a/queue-4.19/scsi-megaraid_sas-fix-megasas_ioc_firmware-regressio.patch b/queue-4.19/scsi-megaraid_sas-fix-megasas_ioc_firmware-regressio.patch new file mode 100644 index 00000000000..60db4cb2f35 --- /dev/null +++ b/queue-4.19/scsi-megaraid_sas-fix-megasas_ioc_firmware-regressio.patch @@ -0,0 +1,80 @@ +From d07b4f02e0ca8b060d959d442e6fc045ec6a0d5e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 5 Jan 2021 00:41:04 +0100 +Subject: scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression + +From: Arnd Bergmann + +[ Upstream commit b112036535eda34460677ea883eaecc3a45a435d ] + +Phil Oester reported that a fix for a possible buffer overrun that I sent +caused a regression that manifests in this output: + + Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0. + Severity: Critical + Message ID: PCI1308 + +The original code tried to handle the sense data pointer differently when +using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t +value of 0x11223344 to get stored + +32-bit kernel: 44 33 22 11 ?? ?? ?? ?? +64-bit LE kernel: 44 33 22 11 00 00 00 00 +64-bit BE kernel: 00 00 00 00 44 33 22 11 + +or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as + +32-bit kernel: 88 77 66 55 ?? ?? ?? ?? +64-bit kernel: 88 77 66 55 44 33 22 11 + +In my patch, I tried to ensure that the same value is used on both 32-bit +and 64-bit kernels, and picked what seemed to be the most sensible +combination, storing 32-bit addresses in the first four bytes (as 32-bit +kernels already did), and 64-bit addresses in eight consecutive bytes (as +64-bit kernels already did), but evidently this was incorrect. + +Always storing the dma_addr_t pointer as 64-bit little-endian, +i.e. initializing the second four bytes to zero in case of 32-bit +addressing, apparently solved the problem for Phil, and is consistent with +what all 64-bit little-endian machines did before. + +I also checked in the history that in previous versions of the code, the +pointer was always in the first four bytes without padding, and that +previous attempts to fix 64-bit user space, big-endian architectures and +64-bit DMA were clearly flawed and seem to have introduced made this worse. + +Link: https://lore.kernel.org/r/20210104234137.438275-1-arnd@kernel.org +Fixes: 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets") +Fixes: 107a60dd71b5 ("scsi: megaraid_sas: Add support for 64bit consistent DMA") +Fixes: 94cd65ddf4d7 ("[SCSI] megaraid_sas: addded support for big endian architecture") +Fixes: 7b2519afa1ab ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation") +Reported-by: Phil Oester +Tested-by: Phil Oester +Signed-off-by: Arnd Bergmann +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c +index 83d25ee88f028..8877a21102f1d 100644 +--- a/drivers/scsi/megaraid/megaraid_sas_base.c ++++ b/drivers/scsi/megaraid/megaraid_sas_base.c +@@ -7323,11 +7323,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance, + goto out; + } + ++ /* always store 64 bits regardless of addressing */ + sense_ptr = (void *)cmd->frame + ioc->sense_off; +- if (instance->consistent_mask_64bit) +- put_unaligned_le64(sense_handle, sense_ptr); +- else +- put_unaligned_le32(sense_handle, sense_ptr); ++ put_unaligned_le64(sense_handle, sense_ptr); + } + + /* +-- +2.27.0 + diff --git a/queue-4.19/selftests-net-fib_tests-remove-duplicate-log-test.patch b/queue-4.19/selftests-net-fib_tests-remove-duplicate-log-test.patch new file mode 100644 index 00000000000..239319f0410 --- /dev/null +++ b/queue-4.19/selftests-net-fib_tests-remove-duplicate-log-test.patch @@ -0,0 +1,39 @@ +From 2e95200e61fc12e766c2b6c546a5cace0adad1b3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 19 Jan 2021 10:59:30 +0800 +Subject: selftests: net: fib_tests: remove duplicate log test + +From: Hangbin Liu + +[ Upstream commit fd23d2dc180fccfad4b27a8e52ba1bc415d18509 ] + +The previous test added an address with a specified metric and check if +correspond route was created. I somehow added two logs for the same +test. Remove the duplicated one. + +Reported-by: Antoine Tenart +Fixes: 0d29169a708b ("selftests/net/fib_tests: update addr_metric_test for peer route testing") +Signed-off-by: Hangbin Liu +Reviewed-by: David Ahern +Link: https://lore.kernel.org/r/20210119025930.2810532-1-liuhangbin@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + tools/testing/selftests/net/fib_tests.sh | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh +index 67048f922ff20..a5ba149761bf9 100755 +--- a/tools/testing/selftests/net/fib_tests.sh ++++ b/tools/testing/selftests/net/fib_tests.sh +@@ -987,7 +987,6 @@ ipv6_addr_metric_test() + + check_route6 "2001:db8:104::1 dev dummy2 proto kernel metric 260" + log_test $? 0 "Set metric with peer route on local side" +- log_test $? 0 "User specified metric on local address" + check_route6 "2001:db8:104::2 dev dummy2 proto kernel metric 260" + log_test $? 0 "Set metric with peer route on peer side" + +-- +2.27.0 + diff --git a/queue-4.19/series b/queue-4.19/series index 69ebc2db7bc..88c4932eeb9 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -21,3 +21,10 @@ drm-nouveau-privring-ack-interrupts-the-same-way-as-.patch drm-nouveau-i2c-gm200-increase-width-of-aux-semaphor.patch drm-nouveau-mmu-fix-vram-heap-sizing.patch drm-nouveau-kms-nv50-fix-case-where-notifier-buffer-.patch +scsi-megaraid_sas-fix-megasas_ioc_firmware-regressio.patch +i2c-octeon-check-correct-size-of-maximum-recv_len-pa.patch +platform-x86-intel-vbtn-drop-hp-stream-x360-converti.patch +selftests-net-fib_tests-remove-duplicate-log-test.patch +can-dev-can_restart-fix-use-after-free-bug.patch +can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch +can-peak_usb-fix-use-after-free-bugs.patch