]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.4
authorSasha Levin <sashal@kernel.org>
Sun, 4 Dec 2022 02:26:50 +0000 (21:26 -0500)
committerSasha Levin <sashal@kernel.org>
Sun, 4 Dec 2022 02:26:50 +0000 (21:26 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
12 files changed:
queue-5.4/asoc-ops-fix-bounds-check-for-_sx-controls.patch [new file with mode: 0644]
queue-5.4/iommu-vt-d-fix-pci-device-refcount-leak-in-dmar_dev_.patch [new file with mode: 0644]
queue-5.4/ipv4-fix-route-deletion-when-nexthop-info-is-not-spe.patch [new file with mode: 0644]
queue-5.4/ipv4-handle-attempt-to-delete-multipath-route-when-f.patch [new file with mode: 0644]
queue-5.4/kconfig.debug-provide-a-little-extra-frame_warn-leew.patch [new file with mode: 0644]
queue-5.4/parisc-increase-frame_warn-to-2048-bytes-on-parisc.patch [new file with mode: 0644]
queue-5.4/parisc-increase-size-of-gcc-stack-frame-check.patch [new file with mode: 0644]
queue-5.4/pinctrl-single-fix-potential-division-by-zero.patch [new file with mode: 0644]
queue-5.4/selftests-net-add-delete-nexthop-route-warning-test.patch [new file with mode: 0644]
queue-5.4/selftests-net-fix-nexthop-warning-cleanup-double-ip-.patch [new file with mode: 0644]
queue-5.4/series
queue-5.4/xtensa-increase-size-of-gcc-stack-frame-check.patch [new file with mode: 0644]

diff --git a/queue-5.4/asoc-ops-fix-bounds-check-for-_sx-controls.patch b/queue-5.4/asoc-ops-fix-bounds-check-for-_sx-controls.patch
new file mode 100644 (file)
index 0000000..c51a149
--- /dev/null
@@ -0,0 +1,39 @@
+From 1c3304eedd2c027e4c9768a1d0541f7ad8406eb7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 May 2022 14:41:36 +0100
+Subject: ASoC: ops: Fix bounds check for _sx controls
+
+From: Mark Brown <broonie@kernel.org>
+
+[ Upstream commit 698813ba8c580efb356ace8dbf55f61dac6063a8 ]
+
+For _sx controls the semantics of the max field is not the usual one, max
+is the number of steps rather than the maximum value. This means that our
+check in snd_soc_put_volsw_sx() needs to just check against the maximum
+value.
+
+Fixes: 4f1e50d6a9cf9c1b ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()")
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Link: https://lore.kernel.org/r/20220511134137.169575-1-broonie@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/soc-ops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
+index 453b61b42dd9..2faf95d4bb75 100644
+--- a/sound/soc/soc-ops.c
++++ b/sound/soc/soc-ops.c
+@@ -445,7 +445,7 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol,
+       val = ucontrol->value.integer.value[0];
+       if (mc->platform_max && val > mc->platform_max)
+               return -EINVAL;
+-      if (val > max - min)
++      if (val > max)
+               return -EINVAL;
+       if (val < 0)
+               return -EINVAL;
+-- 
+2.35.1
+
diff --git a/queue-5.4/iommu-vt-d-fix-pci-device-refcount-leak-in-dmar_dev_.patch b/queue-5.4/iommu-vt-d-fix-pci-device-refcount-leak-in-dmar_dev_.patch
new file mode 100644 (file)
index 0000000..221372d
--- /dev/null
@@ -0,0 +1,43 @@
+From 378606ae64cdcbdd816412e4361f97fb751c8998 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Dec 2022 12:01:27 +0800
+Subject: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()
+
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+
+[ Upstream commit 4bedbbd782ebbe7287231fea862c158d4f08a9e3 ]
+
+for_each_pci_dev() is implemented by pci_get_device(). The comment of
+pci_get_device() says that it will increase the reference count for the
+returned pci_dev and also decrease the reference count for the input
+pci_dev @from if it is not NULL.
+
+If we break for_each_pci_dev() loop with pdev not NULL, we need to call
+pci_dev_put() to decrease the reference count. Add the missing
+pci_dev_put() for the error path to avoid reference count leak.
+
+Fixes: 2e4552893038 ("iommu/vt-d: Unify the way to process DMAR device scope array")
+Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Link: https://lore.kernel.org/r/20221121113649.190393-3-wangxiongfeng2@huawei.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/dmar.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
+index 9f881fc102f7..36900d65386f 100644
+--- a/drivers/iommu/dmar.c
++++ b/drivers/iommu/dmar.c
+@@ -794,6 +794,7 @@ int __init dmar_dev_scope_init(void)
+                       info = dmar_alloc_pci_notify_info(dev,
+                                       BUS_NOTIFY_ADD_DEVICE);
+                       if (!info) {
++                              pci_dev_put(dev);
+                               return dmar_dev_scope_status;
+                       } else {
+                               dmar_pci_bus_add_dev(info);
+-- 
+2.35.1
+
diff --git a/queue-5.4/ipv4-fix-route-deletion-when-nexthop-info-is-not-spe.patch b/queue-5.4/ipv4-fix-route-deletion-when-nexthop-info-is-not-spe.patch
new file mode 100644 (file)
index 0000000..bfd5a85
--- /dev/null
@@ -0,0 +1,118 @@
+From c275047a23e7ea20ba75f194b4807ed1afeca4ca Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 24 Nov 2022 23:09:32 +0200
+Subject: ipv4: Fix route deletion when nexthop info is not specified
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit d5082d386eee7e8ec46fa8581932c81a4961dcef ]
+
+When the kernel receives a route deletion request from user space it
+tries to delete a route that matches the route attributes specified in
+the request.
+
+If only prefix information is specified in the request, the kernel
+should delete the first matching FIB alias regardless of its associated
+FIB info. However, an error is currently returned when the FIB info is
+backed by a nexthop object:
+
+ # ip nexthop add id 1 via 192.0.2.2 dev dummy10
+ # ip route add 198.51.100.0/24 nhid 1
+ # ip route del 198.51.100.0/24
+ RTNETLINK answers: No such process
+
+Fix by matching on such a FIB info when legacy nexthop attributes are
+not specified in the request. An earlier check already covers the case
+where a nexthop ID is specified in the request.
+
+Add tests that cover these flows. Before the fix:
+
+ # ./fib_nexthops.sh -t ipv4_fcnal
+ ...
+ TEST: Delete route when not specifying nexthop attributes           [FAIL]
+
+ Tests passed:  11
+ Tests failed:   1
+
+After the fix:
+
+ # ./fib_nexthops.sh -t ipv4_fcnal
+ ...
+ TEST: Delete route when not specifying nexthop attributes           [ OK ]
+
+ Tests passed:  12
+ Tests failed:   0
+
+No regressions in other tests:
+
+ # ./fib_nexthops.sh
+ ...
+ Tests passed: 228
+ Tests failed:   0
+
+ # ./fib_tests.sh
+ ...
+ Tests passed: 186
+ Tests failed:   0
+
+Cc: stable@vger.kernel.org
+Reported-by: Jonas Gorski <jonas.gorski@gmail.com>
+Tested-by: Jonas Gorski <jonas.gorski@gmail.com>
+Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects")
+Fixes: 6bf92d70e690 ("net: ipv4: fix route with nexthop object delete warning")
+Fixes: 61b91eb33a69 ("ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20221124210932.2470010-1-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/fib_semantics.c                    |  8 +++++---
+ tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
+ 2 files changed, 16 insertions(+), 3 deletions(-)
+
+diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
+index 31424172ff18..908913d75847 100644
+--- a/net/ipv4/fib_semantics.c
++++ b/net/ipv4/fib_semantics.c
+@@ -875,9 +875,11 @@ int fib_nh_match(struct fib_config *cfg, struct fib_info *fi,
+               return 1;
+       }
+-      /* cannot match on nexthop object attributes */
+-      if (fi->nh)
+-              return 1;
++      if (fi->nh) {
++              if (cfg->fc_oif || cfg->fc_gw_family || cfg->fc_mp)
++                      return 1;
++              return 0;
++      }
+       if (cfg->fc_oif || cfg->fc_gw_family) {
+               struct fib_nh *nh;
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 28f5121fac44..0bdca3a2e673 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -602,6 +602,17 @@ ipv4_fcnal()
+       run_cmd "$IP ro add 172.16.101.0/24 nhid 21"
+       run_cmd "$IP ro del 172.16.101.0/24 nexthop via 172.16.1.7 dev veth1 nexthop via 172.16.1.8 dev veth1"
+       log_test $? 2 "Delete multipath route with only nh id based entry"
++
++      run_cmd "$IP nexthop add id 22 via 172.16.1.6 dev veth1"
++      run_cmd "$IP ro add 172.16.102.0/24 nhid 22"
++      run_cmd "$IP ro del 172.16.102.0/24 dev veth1"
++      log_test $? 2 "Delete route when specifying only nexthop device"
++
++      run_cmd "$IP ro del 172.16.102.0/24 via 172.16.1.6"
++      log_test $? 2 "Delete route when specifying only gateway"
++
++      run_cmd "$IP ro del 172.16.102.0/24"
++      log_test $? 0 "Delete route when not specifying nexthop attributes"
+ }
+ ipv4_grp_fcnal()
+-- 
+2.35.1
+
diff --git a/queue-5.4/ipv4-handle-attempt-to-delete-multipath-route-when-f.patch b/queue-5.4/ipv4-handle-attempt-to-delete-multipath-route-when-f.patch
new file mode 100644 (file)
index 0000000..39cf896
--- /dev/null
@@ -0,0 +1,75 @@
+From 68a22c7251292c22feda1f292602bd7db1daf4be Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 6 Oct 2022 10:48:49 -0600
+Subject: ipv4: Handle attempt to delete multipath route when fib_info contains
+ an nh reference
+
+From: David Ahern <dsahern@kernel.org>
+
+[ Upstream commit 61b91eb33a69c3be11b259c5ea484505cd79f883 ]
+
+Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match:
+    fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961
+    fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753
+    inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874
+
+Separate nexthop objects are mutually exclusive with the legacy
+multipath spec. Fix fib_nh_match to return if the config for the
+to be deleted route contains a multipath spec while the fib_info
+is using a nexthop object.
+
+Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects")
+Fixes: 6bf92d70e690 ("net: ipv4: fix route with nexthop object delete warning")
+Reported-by: Gwangun Jung <exsociety@gmail.com>
+Signed-off-by: David Ahern <dsahern@kernel.org>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Tested-by: Ido Schimmel <idosch@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Stable-dep-of: d5082d386eee ("ipv4: Fix route deletion when nexthop info is not specified")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/fib_semantics.c                    | 8 ++++----
+ tools/testing/selftests/net/fib_nexthops.sh | 5 +++++
+ 2 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
+index 28da0443f3e9..31424172ff18 100644
+--- a/net/ipv4/fib_semantics.c
++++ b/net/ipv4/fib_semantics.c
+@@ -875,13 +875,13 @@ int fib_nh_match(struct fib_config *cfg, struct fib_info *fi,
+               return 1;
+       }
++      /* cannot match on nexthop object attributes */
++      if (fi->nh)
++              return 1;
++
+       if (cfg->fc_oif || cfg->fc_gw_family) {
+               struct fib_nh *nh;
+-              /* cannot match on nexthop object attributes */
+-              if (fi->nh)
+-                      return 1;
+-
+               nh = fib_info_nh(fi, 0);
+               if (cfg->fc_encap) {
+                       if (fib_encap_match(cfg->fc_encap_type, cfg->fc_encap,
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 7b154b61d108..28f5121fac44 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -597,6 +597,11 @@ ipv4_fcnal()
+       log_test $rc 0 "Delete nexthop route warning"
+       run_cmd "$IP route delete 172.16.101.1/32 nhid 12"
+       run_cmd "$IP nexthop del id 12"
++
++      run_cmd "$IP nexthop add id 21 via 172.16.1.6 dev veth1"
++      run_cmd "$IP ro add 172.16.101.0/24 nhid 21"
++      run_cmd "$IP ro del 172.16.101.0/24 nexthop via 172.16.1.7 dev veth1 nexthop via 172.16.1.8 dev veth1"
++      log_test $? 2 "Delete multipath route with only nh id based entry"
+ }
+ ipv4_grp_fcnal()
+-- 
+2.35.1
+
diff --git a/queue-5.4/kconfig.debug-provide-a-little-extra-frame_warn-leew.patch b/queue-5.4/kconfig.debug-provide-a-little-extra-frame_warn-leew.patch
new file mode 100644 (file)
index 0000000..414e267
--- /dev/null
@@ -0,0 +1,56 @@
+From 4a82ceb9d6b3351e5b13cc59e175c3535eaacbe9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 25 Nov 2022 12:07:50 +0000
+Subject: Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is
+ enabled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lee Jones <lee@kernel.org>
+
+[ Upstream commit 152fe65f300e1819d59b80477d3e0999b4d5d7d2 ]
+
+When enabled, KASAN enlarges function's stack-frames.  Pushing quite a few
+over the current threshold.  This can mainly be seen on 32-bit
+architectures where the present limit (when !GCC) is a lowly 1024-Bytes.
+
+Link: https://lkml.kernel.org/r/20221125120750.3537134-3-lee@kernel.org
+Signed-off-by: Lee Jones <lee@kernel.org>
+Acked-by: Arnd Bergmann <arnd@arndb.de>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: "Christian König" <christian.koenig@amd.com>
+Cc: Daniel Vetter <daniel@ffwll.ch>
+Cc: David Airlie <airlied@gmail.com>
+Cc: Harry Wentland <harry.wentland@amd.com>
+Cc: Leo Li <sunpeng.li@amd.com>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: Nathan Chancellor <nathan@kernel.org>
+Cc: Nick Desaulniers <ndesaulniers@google.com>
+Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
+Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: Tom Rix <trix@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/Kconfig.debug | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
+index 3ab05ca63c6e..6d79e7c3219c 100644
+--- a/lib/Kconfig.debug
++++ b/lib/Kconfig.debug
+@@ -255,6 +255,7 @@ config FRAME_WARN
+       default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+       default 2048 if PARISC
+       default 1536 if (!64BIT && XTENSA)
++      default 1280 if KASAN && !64BIT
+       default 1024 if !64BIT
+       default 2048 if 64BIT
+       help
+-- 
+2.35.1
+
diff --git a/queue-5.4/parisc-increase-frame_warn-to-2048-bytes-on-parisc.patch b/queue-5.4/parisc-increase-frame_warn-to-2048-bytes-on-parisc.patch
new file mode 100644 (file)
index 0000000..7794df3
--- /dev/null
@@ -0,0 +1,40 @@
+From ebf09b19c2b7793c8800c2b92f4bfd9d63c3d478 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 19 Nov 2021 22:31:03 +0100
+Subject: parisc: Increase FRAME_WARN to 2048 bytes on parisc
+
+From: Helge Deller <deller@gmx.de>
+
+[ Upstream commit 8d192bec534bd5b778135769a12e5f04580771f7 ]
+
+PA-RISC uses a much bigger frame size for functions than other
+architectures. So increase it to 2048 for 32- and 64-bit kernels.
+This fixes e.g. a warning in lib/xxhash.c.
+
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Stable-dep-of: 152fe65f300e ("Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/Kconfig.debug | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
+index 42b6fff962b7..3ab05ca63c6e 100644
+--- a/lib/Kconfig.debug
++++ b/lib/Kconfig.debug
+@@ -253,8 +253,9 @@ config FRAME_WARN
+       int "Warn for stack frames larger than (needs gcc 4.4)"
+       range 0 8192
+       default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+-      default 1536 if (!64BIT && (PARISC || XTENSA))
+-      default 1024 if (!64BIT && !PARISC)
++      default 2048 if PARISC
++      default 1536 if (!64BIT && XTENSA)
++      default 1024 if !64BIT
+       default 2048 if 64BIT
+       help
+         Tell gcc to warn at build time for stack frames larger than this.
+-- 
+2.35.1
+
diff --git a/queue-5.4/parisc-increase-size-of-gcc-stack-frame-check.patch b/queue-5.4/parisc-increase-size-of-gcc-stack-frame-check.patch
new file mode 100644 (file)
index 0000000..8d6d091
--- /dev/null
@@ -0,0 +1,38 @@
+From 9b3d8991c463cf14726d4f2b36c05c59e275c492 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Jul 2021 15:38:08 +0200
+Subject: parisc: Increase size of gcc stack frame check
+
+From: Helge Deller <deller@gmx.de>
+
+[ Upstream commit 55b70eed81cba1331773d4aaf5cba2bb07475cd8 ]
+
+parisc uses much bigger frames than other architectures, so increase the
+stack frame check value to avoid compiler warnings.
+
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Stable-dep-of: 152fe65f300e ("Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/Kconfig.debug | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
+index b3d0d047369c..f610b47b74cc 100644
+--- a/lib/Kconfig.debug
++++ b/lib/Kconfig.debug
+@@ -253,7 +253,7 @@ config FRAME_WARN
+       int "Warn for stack frames larger than (needs gcc 4.4)"
+       range 0 8192
+       default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+-      default 1280 if (!64BIT && PARISC)
++      default 1536 if (!64BIT && PARISC)
+       default 1024 if (!64BIT && !PARISC)
+       default 2048 if 64BIT
+       help
+-- 
+2.35.1
+
diff --git a/queue-5.4/pinctrl-single-fix-potential-division-by-zero.patch b/queue-5.4/pinctrl-single-fix-potential-division-by-zero.patch
new file mode 100644 (file)
index 0000000..4082c74
--- /dev/null
@@ -0,0 +1,43 @@
+From 0697136c4e5536aa883f548f52e4cd6de53a3315 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Nov 2022 15:30:34 +0300
+Subject: pinctrl: single: Fix potential division by zero
+
+From: Maxim Korotkov <korotkov.maxim.s@gmail.com>
+
+[ Upstream commit 64c150339e7f6c5cbbe8c17a56ef2b3902612798 ]
+
+There is a possibility of dividing by zero due to the pcs->bits_per_pin
+if pcs->fmask() also has a value of zero and called fls
+from asm-generic/bitops/builtin-fls.h or arch/x86/include/asm/bitops.h.
+The function pcs_probe() has the branch that assigned to fmask 0 before
+pcs_allocate_pin_table() was called
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
+Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
+Reviewed-by: Tony Lindgren <tony@atomide.com>
+Link: https://lore.kernel.org/r/20221117123034.27383-1-korotkov.maxim.s@gmail.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/pinctrl-single.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
+index fb1c8965cb99..20c89023d312 100644
+--- a/drivers/pinctrl/pinctrl-single.c
++++ b/drivers/pinctrl/pinctrl-single.c
+@@ -703,7 +703,7 @@ static int pcs_allocate_pin_table(struct pcs_device *pcs)
+       mux_bytes = pcs->width / BITS_PER_BYTE;
+-      if (pcs->bits_per_mux) {
++      if (pcs->bits_per_mux && pcs->fmask) {
+               pcs->bits_per_pin = fls(pcs->fmask);
+               nr_pins = (pcs->size * BITS_PER_BYTE) / pcs->bits_per_pin;
+               num_pins_in_register = pcs->width / pcs->bits_per_pin;
+-- 
+2.35.1
+
diff --git a/queue-5.4/selftests-net-add-delete-nexthop-route-warning-test.patch b/queue-5.4/selftests-net-add-delete-nexthop-route-warning-test.patch
new file mode 100644 (file)
index 0000000..a6aac68
--- /dev/null
@@ -0,0 +1,60 @@
+From a3368134c295c79b91a010b73e7f171e56d1a6b6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 1 Apr 2022 10:33:43 +0300
+Subject: selftests: net: add delete nexthop route warning test
+
+From: Nikolay Aleksandrov <razor@blackwall.org>
+
+[ Upstream commit 392baa339c6a42a2cb088e5e5df2b59b8f89be24 ]
+
+Add a test which causes a WARNING on kernels which treat a
+nexthop route like a normal route when comparing for deletion and a
+device is specified. That is, a route is found but we hit a warning while
+matching it. The warning is from fib_info_nh() in include/net/nexthop.h
+because we run it on a fib_info with nexthop object. The call chain is:
+ inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a
+nexthop fib_info and also with fc_oif set thus calling fib_info_nh on
+the fib_info and triggering the warning).
+
+Repro steps:
+ $ ip nexthop add id 12 via 172.16.1.3 dev veth1
+ $ ip route add 172.16.101.1/32 nhid 12
+ $ ip route delete 172.16.101.1/32 dev veth1
+
+Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Stable-dep-of: d5082d386eee ("ipv4: Fix route deletion when nexthop info is not specified")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 09830b88ec8c..06c3694c64a5 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -583,6 +583,20 @@ ipv4_fcnal()
+       set +e
+       check_nexthop "dev veth1" ""
+       log_test $? 0 "Nexthops removed on admin down"
++
++      # nexthop route delete warning: route add with nhid and delete
++      # using device
++      run_cmd "$IP li set dev veth1 up"
++      run_cmd "$IP nexthop add id 12 via 172.16.1.3 dev veth1"
++      out1=`dmesg | grep "WARNING:.*fib_nh_match.*" | wc -l`
++      run_cmd "$IP route add 172.16.101.1/32 nhid 12"
++      run_cmd "$IP route delete 172.16.101.1/32 dev veth1"
++      out2=`dmesg | grep "WARNING:.*fib_nh_match.*" | wc -l`
++      [ $out1 -eq $out2 ]
++      rc=$?
++      log_test $rc 0 "Delete nexthop route warning"
++      run_cmd "$IP ip route delete 172.16.101.1/32 nhid 12"
++      run_cmd "$IP ip nexthop del id 12"
+ }
+ ipv4_grp_fcnal()
+-- 
+2.35.1
+
diff --git a/queue-5.4/selftests-net-fix-nexthop-warning-cleanup-double-ip-.patch b/queue-5.4/selftests-net-fix-nexthop-warning-cleanup-double-ip-.patch
new file mode 100644 (file)
index 0000000..be83ce6
--- /dev/null
@@ -0,0 +1,41 @@
+From a3ca75882a8cbc11e3ae0bad59d02fb24f8c05b0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 1 Apr 2022 18:54:27 +0300
+Subject: selftests: net: fix nexthop warning cleanup double ip typo
+
+From: Nikolay Aleksandrov <razor@blackwall.org>
+
+[ Upstream commit 692930cc435099580a4b9e32fa781b0688c18439 ]
+
+I made a stupid typo when adding the nexthop route warning selftest and
+added both $IP and ip after it (double ip) on the cleanup path. The
+error doesn't show up when running the test, but obviously it doesn't
+cleanup properly after it.
+
+Fixes: 392baa339c6a ("selftests: net: add delete nexthop route warning test")
+Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Stable-dep-of: d5082d386eee ("ipv4: Fix route deletion when nexthop info is not specified")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 06c3694c64a5..7b154b61d108 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -595,8 +595,8 @@ ipv4_fcnal()
+       [ $out1 -eq $out2 ]
+       rc=$?
+       log_test $rc 0 "Delete nexthop route warning"
+-      run_cmd "$IP ip route delete 172.16.101.1/32 nhid 12"
+-      run_cmd "$IP ip nexthop del id 12"
++      run_cmd "$IP route delete 172.16.101.1/32 nhid 12"
++      run_cmd "$IP nexthop del id 12"
+ }
+ ipv4_grp_fcnal()
+-- 
+2.35.1
+
index 25aefe6b45d391d6c919418603d5d6222f5daa87..4fc04ed9e270692f3cfa9564f1bcf15b7fa35e3d 100644 (file)
@@ -134,3 +134,14 @@ tracing-free-buffers-when-a-used-dynamic-event-is-removed.patch
 arm64-fix-panic-when-spectre-v2-causes-spectre-bhb-to-re-allocate-kvm-vectors.patch
 arm64-errata-fix-kvm-spectre-v2-mitigation-selection-for-cortex-a57-a72.patch
 mm-fix-.data.once-orphan-section-warning.patch
+asoc-ops-fix-bounds-check-for-_sx-controls.patch
+pinctrl-single-fix-potential-division-by-zero.patch
+iommu-vt-d-fix-pci-device-refcount-leak-in-dmar_dev_.patch
+parisc-increase-size-of-gcc-stack-frame-check.patch
+xtensa-increase-size-of-gcc-stack-frame-check.patch
+parisc-increase-frame_warn-to-2048-bytes-on-parisc.patch
+kconfig.debug-provide-a-little-extra-frame_warn-leew.patch
+selftests-net-add-delete-nexthop-route-warning-test.patch
+selftests-net-fix-nexthop-warning-cleanup-double-ip-.patch
+ipv4-handle-attempt-to-delete-multipath-route-when-f.patch
+ipv4-fix-route-deletion-when-nexthop-info-is-not-spe.patch
diff --git a/queue-5.4/xtensa-increase-size-of-gcc-stack-frame-check.patch b/queue-5.4/xtensa-increase-size-of-gcc-stack-frame-check.patch
new file mode 100644 (file)
index 0000000..128d93e
--- /dev/null
@@ -0,0 +1,46 @@
+From 711562ebd164eb226f3ed04034f3f5f467ee17f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 24 Sep 2021 15:43:29 -0700
+Subject: xtensa: increase size of gcc stack frame check
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+[ Upstream commit 867050247e295cf20fce046a92a7e6491fcfe066 ]
+
+xtensa frame size is larger than the frame size for almost all other
+architectures.  This results in more than 50 "the frame size of <n> is
+larger than 1024 bytes" errors when trying to build xtensa:allmodconfig.
+
+Increase frame size for xtensa to 1536 bytes to avoid compile errors due
+to frame size limits.
+
+Link: https://lkml.kernel.org/r/20210912025235.3514761-1-linux@roeck-us.net
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
+Cc: Chris Zankel <chris@zankel.net>
+Cc: David Laight <David.Laight@ACULAB.COM>
+Cc: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Stable-dep-of: 152fe65f300e ("Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/Kconfig.debug | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
+index f610b47b74cc..42b6fff962b7 100644
+--- a/lib/Kconfig.debug
++++ b/lib/Kconfig.debug
+@@ -253,7 +253,7 @@ config FRAME_WARN
+       int "Warn for stack frames larger than (needs gcc 4.4)"
+       range 0 8192
+       default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+-      default 1536 if (!64BIT && PARISC)
++      default 1536 if (!64BIT && (PARISC || XTENSA))
+       default 1024 if (!64BIT && !PARISC)
+       default 2048 if 64BIT
+       help
+-- 
+2.35.1
+