]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.4
authorSasha Levin <sashal@kernel.org>
Sat, 4 Dec 2021 03:40:00 +0000 (22:40 -0500)
committerSasha Levin <sashal@kernel.org>
Sat, 4 Dec 2021 03:40:00 +0000 (22:40 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.4/net-ethernet-dec-tulip-de4x5-fix-possible-array-over.patch [new file with mode: 0644]
queue-4.4/net-return-correct-error-code.patch [new file with mode: 0644]
queue-4.4/net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch [new file with mode: 0644]
queue-4.4/platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch [new file with mode: 0644]
queue-4.4/s390-setup-avoid-using-memblock_enforce_memory_limit.patch [new file with mode: 0644]
queue-4.4/scsi-iscsi-unblock-session-then-wake-up-error-handle.patch [new file with mode: 0644]
queue-4.4/series

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 (file)
index 0000000..7a7c6d8
--- /dev/null
@@ -0,0 +1,58 @@
+From 4e388a49ac82e73efe86d80fa9aab9031ad00623 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <starmiku1207184332@gmail.com>
+
+[ 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 <oslab@tsinghua.edu.cn>
+Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 (file)
index 0000000..07d01ae
--- /dev/null
@@ -0,0 +1,35 @@
+From 81ea7ec01af265ed45cc5a0e405d5529973e7190 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Nov 2021 16:14:48 +0800
+Subject: net: return correct error code
+
+From: liuguoqiang <liuguoqiang@uniontech.com>
+
+[ Upstream commit 6def480181f15f6d9ec812bca8cbc62451ba314c ]
+
+When kmemdup called failed and register_net_sysctl return NULL, should
+return ENOMEM instead of ENOBUFS
+
+Signed-off-by: liuguoqiang <liuguoqiang@uniontech.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 (file)
index 0000000..771b16b
--- /dev/null
@@ -0,0 +1,66 @@
+From feaf26b031a21a875c84dd06b92e34ed0f951220 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <zhangyue1@kylinos.cn>
+
+[ 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 <zhangyue1@kylinos.cn>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 (file)
index 0000000..d5d6071
--- /dev/null
@@ -0,0 +1,70 @@
+From bf9c322e961bfb0b3a81bdb3b357aa542121e4e1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <slark_xiao@163.com>
+
+[ 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 <slark_xiao@163.com>
+Link: https://lore.kernel.org/r/20211108060648.8212-1-slark_xiao@163.com
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 (file)
index 0000000..9d87c8f
--- /dev/null
@@ -0,0 +1,56 @@
+From b8b2b9e6c97a3b2abcf840381922d13319210d9b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 14 Oct 2021 13:38:17 +0200
+Subject: s390/setup: avoid using memblock_enforce_memory_limit
+
+From: Vasily Gorbik <gor@linux.ibm.com>
+
+[ 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 <hca@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 (file)
index 0000000..7a7eac9
--- /dev/null
@@ -0,0 +1,53 @@
+From 266405d05df6f842f9d6cbc7e15cf03600e1265c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Nov 2021 17:10:47 -0500
+Subject: scsi: iscsi: Unblock session then wake up error handler
+
+From: Mike Christie <michael.christie@oracle.com>
+
+[ 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 <lduncan@suse.com>
+Signed-off-by: Mike Christie <michael.christie@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
index 587abd9373c35e33c9e6a022f79b9da718d58b5c..60662d8a6e88fceef8d701211a0192f88185be92 100644 (file)
@@ -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