releases/5.10.214/nfp-flower-handle-acti_netdevs-allocation-failure.patch

   1 From fd865a5c0b150b861d4f196dba71fe5beeafc5aa Mon Sep 17 00:00:00 2001
   2 From: Sasha Levin <sashal@kernel.org>
   3 Date: Fri, 8 Mar 2024 22:25:40 +0800
   4 Subject: nfp: flower: handle acti_netdevs allocation failure
   5
   6 From: Duoming Zhou <duoming@zju.edu.cn>
   7
   8 [ Upstream commit 84e95149bd341705f0eca6a7fcb955c548805002 ]
   9
  10 The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
  11 the physical memory has run out. As a result, if we dereference
  12 the acti_netdevs, the null pointer dereference bugs will happen.
  13
  14 This patch adds a check to judge whether allocation failure occurs.
  15 If it happens, the delayed work will be rescheduled and try again.
  16
  17 Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups")
  18 Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
  19 Reviewed-by: Louis Peens <louis.peens@corigine.com>
  20 Link: https://lore.kernel.org/r/20240308142540.9674-1-duoming@zju.edu.cn
  21 Signed-off-by: Jakub Kicinski <kuba@kernel.org>
  22 Signed-off-by: Sasha Levin <sashal@kernel.org>
  23 ---
  24  drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 5 +++++
  25  1 file changed, 5 insertions(+)
  26
  27 diff --git a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
  28 index 63907aeb3884e..3167f9675ae0f 100644
  29 --- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
  30 +++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
  31 @@ -308,6 +308,11 @@ static void nfp_fl_lag_do_work(struct work_struct *work)
  32
  33                 acti_netdevs = kmalloc_array(entry->slave_cnt,
  34                                              sizeof(*acti_netdevs), GFP_KERNEL);
  35 +               if (!acti_netdevs) {
  36 +                       schedule_delayed_work(&lag->work,
  37 +                                             NFP_FL_LAG_DELAY);
  38 +                       continue;
  39 +               }
  40
  41                 /* Include sanity check in the loop. It may be that a bond has
  42                  * changed between processing the last notification and the
  43 --
  44 2.43.0
  45