From: Sasha Levin Date: Sat, 4 Dec 2021 03:40:00 +0000 (-0500) Subject: Fixes for 4.4 X-Git-Tag: v4.4.294~51 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=02b6220c2a1d4157cbf5cd2d5fd05d1818e59706;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.4 Signed-off-by: Sasha Levin --- diff --git a/queue-4.4/net-ethernet-dec-tulip-de4x5-fix-possible-array-over.patch b/queue-4.4/net-ethernet-dec-tulip-de4x5-fix-possible-array-over.patch new file mode 100644 index 00000000000..7a7c6d81d4f --- /dev/null +++ b/queue-4.4/net-ethernet-dec-tulip-de4x5-fix-possible-array-over.patch @@ -0,0 +1,58 @@ +From 4e388a49ac82e73efe86d80fa9aab9031ad00623 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Nov 2021 15:01:18 +0800 +Subject: net: ethernet: dec: tulip: de4x5: fix possible array overflows in + type3_infoblock() + +From: Teng Qi + +[ Upstream commit 0fa68da72c3be09e06dd833258ee89c33374195f ] + +The definition of macro MOTO_SROM_BUG is: + #define MOTO_SROM_BUG (lp->active == 8 && (get_unaligned_le32( + dev->dev_addr) & 0x00ffffff) == 0x3e0008) + +and the if statement + if (MOTO_SROM_BUG) lp->active = 0; + +using this macro indicates lp->active could be 8. If lp->active is 8 and +the second comparison of this macro is false. lp->active will remain 8 in: + lp->phy[lp->active].gep = (*p ? p : NULL); p += (2 * (*p) + 1); + lp->phy[lp->active].rst = (*p ? p : NULL); p += (2 * (*p) + 1); + lp->phy[lp->active].mc = get_unaligned_le16(p); p += 2; + lp->phy[lp->active].ana = get_unaligned_le16(p); p += 2; + lp->phy[lp->active].fdx = get_unaligned_le16(p); p += 2; + lp->phy[lp->active].ttm = get_unaligned_le16(p); p += 2; + lp->phy[lp->active].mci = *p; + +However, the length of array lp->phy is 8, so array overflows can occur. +To fix these possible array overflows, we first check lp->active and then +return -EINVAL if it is greater or equal to ARRAY_SIZE(lp->phy) (i.e. 8). + +Reported-by: TOTE Robot +Signed-off-by: Teng Qi +Reviewed-by: Arnd Bergmann +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/dec/tulip/de4x5.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c +index 7c4150a83a082..ffc9c7947b93f 100644 +--- a/drivers/net/ethernet/dec/tulip/de4x5.c ++++ b/drivers/net/ethernet/dec/tulip/de4x5.c +@@ -4701,6 +4701,10 @@ type3_infoblock(struct net_device *dev, u_char count, u_char *p) + lp->ibn = 3; + lp->active = *p++; + if (MOTO_SROM_BUG) lp->active = 0; ++ /* if (MOTO_SROM_BUG) statement indicates lp->active could ++ * be 8 (i.e. the size of array lp->phy) */ ++ if (WARN_ON(lp->active >= ARRAY_SIZE(lp->phy))) ++ return -EINVAL; + lp->phy[lp->active].gep = (*p ? p : NULL); p += (2 * (*p) + 1); + lp->phy[lp->active].rst = (*p ? p : NULL); p += (2 * (*p) + 1); + lp->phy[lp->active].mc = get_unaligned_le16(p); p += 2; +-- +2.33.0 + diff --git a/queue-4.4/net-return-correct-error-code.patch b/queue-4.4/net-return-correct-error-code.patch new file mode 100644 index 00000000000..07d01ae1996 --- /dev/null +++ b/queue-4.4/net-return-correct-error-code.patch @@ -0,0 +1,35 @@ +From 81ea7ec01af265ed45cc5a0e405d5529973e7190 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 Nov 2021 16:14:48 +0800 +Subject: net: return correct error code + +From: liuguoqiang + +[ Upstream commit 6def480181f15f6d9ec812bca8cbc62451ba314c ] + +When kmemdup called failed and register_net_sysctl return NULL, should +return ENOMEM instead of ENOBUFS + +Signed-off-by: liuguoqiang +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/ipv4/devinet.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c +index 2cb8612e7821e..35961ae1d120c 100644 +--- a/net/ipv4/devinet.c ++++ b/net/ipv4/devinet.c +@@ -2237,7 +2237,7 @@ static int __devinet_sysctl_register(struct net *net, char *dev_name, + free: + kfree(t); + out: +- return -ENOBUFS; ++ return -ENOMEM; + } + + static void __devinet_sysctl_unregister(struct ipv4_devconf *cnf) +-- +2.33.0 + diff --git a/queue-4.4/net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch b/queue-4.4/net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch new file mode 100644 index 00000000000..771b16bc19c --- /dev/null +++ b/queue-4.4/net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch @@ -0,0 +1,66 @@ +From feaf26b031a21a875c84dd06b92e34ed0f951220 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Nov 2021 13:46:32 +0800 +Subject: net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be + out of bound + +From: zhangyue + +[ Upstream commit 61217be886b5f7402843677e4be7e7e83de9cb41 ] + +In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the +'for' end, the 'k' is 8. + +At this time, the array 'lp->phy[8]' may be out of bound. + +Signed-off-by: zhangyue +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/dec/tulip/de4x5.c | 30 +++++++++++++++----------- + 1 file changed, 17 insertions(+), 13 deletions(-) + +diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c +index 7799cf33cc6e2..7c4150a83a082 100644 +--- a/drivers/net/ethernet/dec/tulip/de4x5.c ++++ b/drivers/net/ethernet/dec/tulip/de4x5.c +@@ -4992,19 +4992,23 @@ mii_get_phy(struct net_device *dev) + } + if ((j == limit) && (i < DE4X5_MAX_MII)) { + for (k=0; k < DE4X5_MAX_PHY && lp->phy[k].id; k++); +- lp->phy[k].addr = i; +- lp->phy[k].id = id; +- lp->phy[k].spd.reg = GENERIC_REG; /* ANLPA register */ +- lp->phy[k].spd.mask = GENERIC_MASK; /* 100Mb/s technologies */ +- lp->phy[k].spd.value = GENERIC_VALUE; /* TX & T4, H/F Duplex */ +- lp->mii_cnt++; +- lp->active++; +- printk("%s: Using generic MII device control. If the board doesn't operate,\nplease mail the following dump to the author:\n", dev->name); +- j = de4x5_debug; +- de4x5_debug |= DEBUG_MII; +- de4x5_dbg_mii(dev, k); +- de4x5_debug = j; +- printk("\n"); ++ if (k < DE4X5_MAX_PHY) { ++ lp->phy[k].addr = i; ++ lp->phy[k].id = id; ++ lp->phy[k].spd.reg = GENERIC_REG; /* ANLPA register */ ++ lp->phy[k].spd.mask = GENERIC_MASK; /* 100Mb/s technologies */ ++ lp->phy[k].spd.value = GENERIC_VALUE; /* TX & T4, H/F Duplex */ ++ lp->mii_cnt++; ++ lp->active++; ++ printk("%s: Using generic MII device control. If the board doesn't operate,\nplease mail the following dump to the author:\n", dev->name); ++ j = de4x5_debug; ++ de4x5_debug |= DEBUG_MII; ++ de4x5_dbg_mii(dev, k); ++ de4x5_debug = j; ++ printk("\n"); ++ } else { ++ goto purgatory; ++ } + } + } + purgatory: +-- +2.33.0 + diff --git a/queue-4.4/platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch b/queue-4.4/platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch new file mode 100644 index 00000000000..d5d60711a10 --- /dev/null +++ b/queue-4.4/platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch @@ -0,0 +1,70 @@ +From bf9c322e961bfb0b3a81bdb3b357aa542121e4e1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 8 Nov 2021 14:06:48 +0800 +Subject: platform/x86: thinkpad_acpi: Fix WWAN device disabled issue after S3 + deep + +From: Slark Xiao + +[ Upstream commit 39f53292181081d35174a581a98441de5da22bc9 ] + +When WWAN device wake from S3 deep, under thinkpad platform, +WWAN would be disabled. This disable status could be checked +by command 'nmcli r wwan' or 'rfkill list'. + +Issue analysis as below: + When host resume from S3 deep, thinkpad_acpi driver would +call hotkey_resume() function. Finnaly, it will use +wan_get_status to check the current status of WWAN device. +During this resume progress, wan_get_status would always +return off even WWAN boot up completely. + In patch V2, Hans said 'sw_state should be unchanged +after a suspend/resume. It's better to drop the +tpacpi_rfk_update_swstate call all together from the +resume path'. + And it's confimed by Lenovo that GWAN is no longer + available from WHL generation because the design does not + match with current pin control. + +Signed-off-by: Slark Xiao +Link: https://lore.kernel.org/r/20211108060648.8212-1-slark_xiao@163.com +Reviewed-by: Hans de Goede +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/thinkpad_acpi.c | 12 ------------ + 1 file changed, 12 deletions(-) + +diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c +index f3954af14f52f..466a0d0162c3d 100644 +--- a/drivers/platform/x86/thinkpad_acpi.c ++++ b/drivers/platform/x86/thinkpad_acpi.c +@@ -1168,15 +1168,6 @@ static int tpacpi_rfk_update_swstate(const struct tpacpi_rfk *tp_rfk) + return status; + } + +-/* Query FW and update rfkill sw state for all rfkill switches */ +-static void tpacpi_rfk_update_swstate_all(void) +-{ +- unsigned int i; +- +- for (i = 0; i < TPACPI_RFK_SW_MAX; i++) +- tpacpi_rfk_update_swstate(tpacpi_rfkill_switches[i]); +-} +- + /* + * Sync the HW-blocking state of all rfkill switches, + * do notice it causes the rfkill core to schedule uevents +@@ -3015,9 +3006,6 @@ static void tpacpi_send_radiosw_update(void) + if (wlsw == TPACPI_RFK_RADIO_OFF) + tpacpi_rfk_update_hwblock_state(true); + +- /* Sync sw blocking state */ +- tpacpi_rfk_update_swstate_all(); +- + /* Sync hw blocking state last if it is hw-unblocked */ + if (wlsw == TPACPI_RFK_RADIO_ON) + tpacpi_rfk_update_hwblock_state(false); +-- +2.33.0 + diff --git a/queue-4.4/s390-setup-avoid-using-memblock_enforce_memory_limit.patch b/queue-4.4/s390-setup-avoid-using-memblock_enforce_memory_limit.patch new file mode 100644 index 00000000000..9d87c8f90c0 --- /dev/null +++ b/queue-4.4/s390-setup-avoid-using-memblock_enforce_memory_limit.patch @@ -0,0 +1,56 @@ +From b8b2b9e6c97a3b2abcf840381922d13319210d9b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 14 Oct 2021 13:38:17 +0200 +Subject: s390/setup: avoid using memblock_enforce_memory_limit + +From: Vasily Gorbik + +[ Upstream commit 5dbc4cb4667457b0c53bcd7bff11500b3c362975 ] + +There is a difference in how architectures treat "mem=" option. For some +that is an amount of online memory, for s390 and x86 this is the limiting +max address. Some memblock api like memblock_enforce_memory_limit() +take limit argument and explicitly treat it as the size of online memory, +and use __find_max_addr to convert it to an actual max address. Current +s390 usage: + +memblock_enforce_memory_limit(memblock_end_of_DRAM()); + +yields different results depending on presence of memory holes (offline +memory blocks in between online memory). If there are no memory holes +limit == max_addr in memblock_enforce_memory_limit() and it does trim +online memory and reserved memory regions. With memory holes present it +actually does nothing. + +Since we already use memblock_remove() explicitly to trim online memory +regions to potential limit (think mem=, kdump, addressing limits, etc.) +drop the usage of memblock_enforce_memory_limit() altogether. Trimming +reserved regions should not be required, since we now use +memblock_set_current_limit() to limit allocations and any explicit memory +reservations above the limit is an actual problem we should not hide. + +Reviewed-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Heiko Carstens +Signed-off-by: Sasha Levin +--- + arch/s390/kernel/setup.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c +index fdc5e76e1f6b0..a765b4936c10c 100644 +--- a/arch/s390/kernel/setup.c ++++ b/arch/s390/kernel/setup.c +@@ -687,9 +687,6 @@ static void __init setup_memory(void) + storage_key_init_range(reg->base, reg->base + reg->size); + } + psw_set_key(PAGE_DEFAULT_KEY); +- +- /* Only cosmetics */ +- memblock_enforce_memory_limit(memblock_end_of_DRAM()); + } + + /* +-- +2.33.0 + diff --git a/queue-4.4/scsi-iscsi-unblock-session-then-wake-up-error-handle.patch b/queue-4.4/scsi-iscsi-unblock-session-then-wake-up-error-handle.patch new file mode 100644 index 00000000000..7a7eac90a62 --- /dev/null +++ b/queue-4.4/scsi-iscsi-unblock-session-then-wake-up-error-handle.patch @@ -0,0 +1,53 @@ +From 266405d05df6f842f9d6cbc7e15cf03600e1265c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Nov 2021 17:10:47 -0500 +Subject: scsi: iscsi: Unblock session then wake up error handler + +From: Mike Christie + +[ Upstream commit a0c2f8b6709a9a4af175497ca65f93804f57b248 ] + +We can race where iscsi_session_recovery_timedout() has woken up the error +handler thread and it's now setting the devices to offline, and +session_recovery_timedout()'s call to scsi_target_unblock() is also trying +to set the device's state to transport-offline. We can then get a mix of +states. + +For the case where we can't relogin we want the devices to be in +transport-offline so when we have repaired the connection +__iscsi_unblock_session() can set the state back to running. + +Set the device state then call into libiscsi to wake up the error handler. + +Link: https://lore.kernel.org/r/20211105221048.6541-2-michael.christie@oracle.com +Reviewed-by: Lee Duncan +Signed-off-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/scsi_transport_iscsi.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c +index 9906a3b562e93..269277c1d9dcc 100644 +--- a/drivers/scsi/scsi_transport_iscsi.c ++++ b/drivers/scsi/scsi_transport_iscsi.c +@@ -1896,12 +1896,12 @@ static void session_recovery_timedout(struct work_struct *work) + } + spin_unlock_irqrestore(&session->lock, flags); + +- if (session->transport->session_recovery_timedout) +- session->transport->session_recovery_timedout(session); +- + ISCSI_DBG_TRANS_SESSION(session, "Unblocking SCSI target\n"); + scsi_target_unblock(&session->dev, SDEV_TRANSPORT_OFFLINE); + ISCSI_DBG_TRANS_SESSION(session, "Completed unblocking SCSI target\n"); ++ ++ if (session->transport->session_recovery_timedout) ++ session->transport->session_recovery_timedout(session); + } + + static void __iscsi_unblock_session(struct work_struct *work) +-- +2.33.0 + diff --git a/queue-4.4/series b/queue-4.4/series index 587abd9373c..60662d8a6e8 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -32,3 +32,9 @@ xen-netfront-disentangle-tx_skb_freelist.patch xen-netfront-don-t-trust-the-backend-response-data-blindly.patch tty-hvc-replace-bug_on-with-negative-return-value.patch hugetlb-take-pmd-sharing-into-account-when-flushing-tlb-caches.patch +net-return-correct-error-code.patch +platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch +s390-setup-avoid-using-memblock_enforce_memory_limit.patch +scsi-iscsi-unblock-session-then-wake-up-error-handle.patch +net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch +net-ethernet-dec-tulip-de4x5-fix-possible-array-over.patch