5.4-stable patches

added patches:
	iavf-fix-limit-of-total-number-of-queues-to-active-queues-of-vf.patch
	mac80211-initialize-variable-have_higher_than_11mbit.patch
	rdma-core-don-t-infoleak-grh-fields.patch
	rdma-uverbs-check-for-null-return-of-kmalloc_array.patch

diff --git a/queue-5.4/iavf-fix-limit-of-total-number-of-queues-to-active-queues-of-vf.patch b/queue-5.4/iavf-fix-limit-of-total-number-of-queues-to-active-queues-of-vf.patch
new file mode 100644 (file)
index 0000000..67013ff
--- /dev/null
+++ b/queue-5.4/iavf-fix-limit-of-total-number-of-queues-to-active-queues-of-vf.patch
@@ -0,0 +1,43 @@
+From b712941c8085e638bb92456e866ed3de4404e3d5 Mon Sep 17 00:00:00 2001
+From: Karen Sornek <karen.sornek@intel.com>
+Date: Wed, 1 Sep 2021 09:21:46 +0200
+Subject: iavf: Fix limit of total number of queues to active queues of VF
+
+From: Karen Sornek <karen.sornek@intel.com>
+
+commit b712941c8085e638bb92456e866ed3de4404e3d5 upstream.
+
+In the absence of this validation, if the user requests to
+configure queues more than the enabled queues, it results in
+sending the requested number of queues to the kernel stack
+(due to the asynchronous nature of VF response), in which
+case the stack might pick a queue to transmit that is not
+enabled and result in Tx hang. Fix this bug by
+limiting the total number of queues allocated for VF to
+active queues of VF.
+
+Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
+Signed-off-by: Ashwin Vijayavel <ashwin.vijayavel@intel.com>
+Signed-off-by: Karen Sornek <karen.sornek@intel.com>
+Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/iavf/iavf_main.c |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
++++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
+@@ -2604,8 +2604,11 @@ static int iavf_validate_ch_config(struc
+               total_max_rate += tx_rate;
+               num_qps += mqprio_qopt->qopt.count[i];
+       }
+-      if (num_qps > IAVF_MAX_REQ_QUEUES)
++      if (num_qps > adapter->num_active_queues) {
++              dev_err(&adapter->pdev->dev,
++                      "Cannot support requested number of queues\n");
+               return -EINVAL;
++      }
+ 
+       ret = iavf_validate_tx_bandwidth(adapter, total_max_rate);
+       return ret;

diff --git a/queue-5.4/mac80211-initialize-variable-have_higher_than_11mbit.patch b/queue-5.4/mac80211-initialize-variable-have_higher_than_11mbit.patch
new file mode 100644 (file)
index 0000000..aa64f82
--- /dev/null
+++ b/queue-5.4/mac80211-initialize-variable-have_higher_than_11mbit.patch
@@ -0,0 +1,41 @@
+From 68a18ad71378a56858141c4449e02a30c829763e Mon Sep 17 00:00:00 2001
+From: Tom Rix <trix@redhat.com>
+Date: Thu, 23 Dec 2021 08:28:48 -0800
+Subject: mac80211: initialize variable have_higher_than_11mbit
+
+From: Tom Rix <trix@redhat.com>
+
+commit 68a18ad71378a56858141c4449e02a30c829763e upstream.
+
+Clang static analysis reports this warnings
+
+mlme.c:5332:7: warning: Branch condition evaluates to a
+  garbage value
+    have_higher_than_11mbit)
+    ^~~~~~~~~~~~~~~~~~~~~~~
+
+have_higher_than_11mbit is only set to true some of the time in
+ieee80211_get_rates() but is checked all of the time.  So
+have_higher_than_11mbit needs to be initialized to false.
+
+Fixes: 5d6a1b069b7f ("mac80211: set basic rates earlier")
+Signed-off-by: Tom Rix <trix@redhat.com>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Link: https://lore.kernel.org/r/20211223162848.3243702-1-trix@redhat.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mac80211/mlme.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -4953,7 +4953,7 @@ static int ieee80211_prep_connection(str
+        */
+       if (new_sta) {
+               u32 rates = 0, basic_rates = 0;
+-              bool have_higher_than_11mbit;
++              bool have_higher_than_11mbit = false;
+               int min_rate = INT_MAX, min_rate_index = -1;
+               const struct cfg80211_bss_ies *ies;
+               int shift = ieee80211_vif_get_shift(&sdata->vif);

diff --git a/queue-5.4/rdma-core-don-t-infoleak-grh-fields.patch b/queue-5.4/rdma-core-don-t-infoleak-grh-fields.patch
new file mode 100644 (file)
index 0000000..4492fb6
--- /dev/null
+++ b/queue-5.4/rdma-core-don-t-infoleak-grh-fields.patch
@@ -0,0 +1,64 @@
+From b35a0f4dd544eaa6162b6d2f13a2557a121ae5fd Mon Sep 17 00:00:00 2001
+From: Leon Romanovsky <leonro@nvidia.com>
+Date: Tue, 4 Jan 2022 14:21:52 +0200
+Subject: RDMA/core: Don't infoleak GRH fields
+
+From: Leon Romanovsky <leonro@nvidia.com>
+
+commit b35a0f4dd544eaa6162b6d2f13a2557a121ae5fd upstream.
+
+If dst->is_global field is not set, the GRH fields are not cleared
+and the following infoleak is reported.
+
+=====================================================
+BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
+BUG: KMSAN: kernel-infoleak in _copy_to_user+0x1c9/0x270 lib/usercopy.c:33
+ instrument_copy_to_user include/linux/instrumented.h:121 [inline]
+ _copy_to_user+0x1c9/0x270 lib/usercopy.c:33
+ copy_to_user include/linux/uaccess.h:209 [inline]
+ ucma_init_qp_attr+0x8c7/0xb10 drivers/infiniband/core/ucma.c:1242
+ ucma_write+0x637/0x6c0 drivers/infiniband/core/ucma.c:1732
+ vfs_write+0x8ce/0x2030 fs/read_write.c:588
+ ksys_write+0x28b/0x510 fs/read_write.c:643
+ __do_sys_write fs/read_write.c:655 [inline]
+ __se_sys_write fs/read_write.c:652 [inline]
+ __ia32_sys_write+0xdb/0x120 fs/read_write.c:652
+ do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]
+ __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180
+ do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205
+ do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248
+ entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
+
+Local variable resp created at:
+ ucma_init_qp_attr+0xa4/0xb10 drivers/infiniband/core/ucma.c:1214
+ ucma_write+0x637/0x6c0 drivers/infiniband/core/ucma.c:1732
+
+Bytes 40-59 of 144 are uninitialized
+Memory access of size 144 starts at ffff888167523b00
+Data copied to user address 0000000020000100
+
+CPU: 1 PID: 25910 Comm: syz-executor.1 Not tainted 5.16.0-rc5-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+=====================================================
+
+Fixes: 4ba66093bdc6 ("IB/core: Check for global flag when using ah_attr")
+Link: https://lore.kernel.org/r/0e9dd51f93410b7b2f4f5562f52befc878b71afa.1641298868.git.leonro@nvidia.com
+Reported-by: syzbot+6d532fa8f9463da290bc@syzkaller.appspotmail.com
+Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/uverbs_marshall.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/core/uverbs_marshall.c
++++ b/drivers/infiniband/core/uverbs_marshall.c
+@@ -66,7 +66,7 @@ void ib_copy_ah_attr_to_user(struct ib_d
+       struct rdma_ah_attr *src = ah_attr;
+       struct rdma_ah_attr conv_ah;
+ 
+-      memset(&dst->grh.reserved, 0, sizeof(dst->grh.reserved));
++      memset(&dst->grh, 0, sizeof(dst->grh));
+ 
+       if ((ah_attr->type == RDMA_AH_ATTR_TYPE_OPA) &&
+           (rdma_ah_get_dlid(ah_attr) > be16_to_cpu(IB_LID_PERMISSIVE)) &&

diff --git a/queue-5.4/rdma-uverbs-check-for-null-return-of-kmalloc_array.patch b/queue-5.4/rdma-uverbs-check-for-null-return-of-kmalloc_array.patch
new file mode 100644 (file)
index 0000000..55784fd
--- /dev/null
+++ b/queue-5.4/rdma-uverbs-check-for-null-return-of-kmalloc_array.patch
@@ -0,0 +1,35 @@
+From 7694a7de22c53a312ea98960fcafc6ec62046531 Mon Sep 17 00:00:00 2001
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Date: Fri, 31 Dec 2021 17:33:15 +0800
+Subject: RDMA/uverbs: Check for null return of kmalloc_array
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+commit 7694a7de22c53a312ea98960fcafc6ec62046531 upstream.
+
+Because of the possible failure of the allocation, data might be NULL
+pointer and will cause the dereference of the NULL pointer later.
+Therefore, it might be better to check it and return -ENOMEM.
+
+Fixes: 6884c6c4bd09 ("RDMA/verbs: Store the write/write_ex uapi entry points in the uverbs_api")
+Link: https://lore.kernel.org/r/20211231093315.1917667-1-jiasheng@iscas.ac.cn
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/uverbs_uapi.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/infiniband/core/uverbs_uapi.c
++++ b/drivers/infiniband/core/uverbs_uapi.c
+@@ -450,6 +450,9 @@ static int uapi_finalize(struct uverbs_a
+       uapi->num_write_ex = max_write_ex + 1;
+       data = kmalloc_array(uapi->num_write + uapi->num_write_ex,
+                            sizeof(*uapi->write_methods), GFP_KERNEL);
++      if (!data)
++              return -ENOMEM;
++
+       for (i = 0; i != uapi->num_write + uapi->num_write_ex; i++)
+               data[i] = &uapi->notsupp_method;
+       uapi->write_methods = data;

diff --git a/queue-5.4/series b/queue-5.4/series
index 62f93ea6cbc7ece707fc12ef1c43e052a2846d06..a0e181128f60cf0d4b3f7544e96d251efcbacde2 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -4,3 +4,7 @@ selftests-x86-fix-warn-in-test_process_vm_readv.patch
 tracing-fix-check-for-trace_percpu_buffer-validity-in-get_trace_buf.patch
 tracing-tag-trace_percpu_buffer-as-a-percpu-pointer.patch
 ieee802154-atusb-fix-uninit-value-in-atusb_set_extended_addr.patch
+iavf-fix-limit-of-total-number-of-queues-to-active-queues-of-vf.patch
+rdma-core-don-t-infoleak-grh-fields.patch
+rdma-uverbs-check-for-null-return-of-kmalloc_array.patch
+mac80211-initialize-variable-have_higher_than_11mbit.patch