diff mbox series

nfp: flower: Added pointer check and continue.

Message ID 20231117125701.58927-1-arefev@swemel.ru
State New
Headers
Series nfp: flower: Added pointer check and continue. |

Commit Message

Denis Arefev Nov. 17, 2023, 12:57 p.m. UTC 
  Return value of a function 'kmalloc_array' is dereferenced at
lag_conf.c without checking for null, but it is usually
checked for this function.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Denis Arefev <arefev@swemel.ru>
---
 drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Louis Peens Nov. 17, 2023, 2:27 p.m. UTC | #1 
On Fri, Nov 17, 2023 at 03:57:01PM +0300, Denis Arefev wrote:
> 
> Return value of a function 'kmalloc_array' is dereferenced at
> lag_conf.c without checking for null, but it is usually
> checked for this function.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Signed-off-by: Denis Arefev <arefev@swemel.ru>
> ---
>  drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> index 88d6d992e7d0..8cc6cce73283 100644
> --- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> @@ -339,6 +339,11 @@ static void nfp_fl_lag_do_work(struct work_struct *work)
>                 acti_netdevs = kmalloc_array(entry->slave_cnt,
>                                              sizeof(*acti_netdevs), GFP_KERNEL);
> 
> +               if (!acti_netdevs) {
> +                       schedule_delayed_work(&lag->work, NFP_FL_LAG_DELAY);
> +                       continue;
> +               }
> +
Thanks for reporting this Denis, it definitely seems to be an oversight.
Would you mind adding a 'nfp_flower_cmsg_warn' here as well, so that
this case does not go undetected? Maybe something like "cannot
allocate memory for group processing" can work.

>                 /* Include sanity check in the loop. It may be that a bond has
>                  * changed between processing the last notification and the
>                  * work queue triggering. If the number of slaves has changed
> --
> 2.25.1
>
Jakub Kicinski Nov. 19, 2023, 4:22 a.m. UTC | #2 
On Fri, 17 Nov 2023 16:27:17 +0200 Louis Peens wrote:
> >                 acti_netdevs = kmalloc_array(entry->slave_cnt,
> >                                              sizeof(*acti_netdevs), GFP_KERNEL);
> > 

Unnecessary new line, please remove it.
There should be no empty lines between call and error check.

> > +               if (!acti_netdevs) {
> > +                       schedule_delayed_work(&lag->work, NFP_FL_LAG_DELAY);
> > +                       continue;
> > +               }
> > +  
> Thanks for reporting this Denis, it definitely seems to be an oversight.
> Would you mind adding a 'nfp_flower_cmsg_warn' here as well, so that
> this case does not go undetected? Maybe something like "cannot
> allocate memory for group processing" can work.

There's a checkpatch check against printing warnings on allocation
failures. Kernel will complain loudly on OOM, anyway, there's no need
for a local print.
Louis Peens Nov. 20, 2023, 7:04 a.m. UTC | #3 
On Sat, Nov 18, 2023 at 08:22:07PM -0800, Jakub Kicinski wrote:
> On Fri, 17 Nov 2023 16:27:17 +0200 Louis Peens wrote:
> > >                 acti_netdevs = kmalloc_array(entry->slave_cnt,
> > >                                              sizeof(*acti_netdevs), GFP_KERNEL);
> > > 
> 
> Unnecessary new line, please remove it.
> There should be no empty lines between call and error check.
> 
> > > +               if (!acti_netdevs) {
> > > +                       schedule_delayed_work(&lag->work, NFP_FL_LAG_DELAY);
> > > +                       continue;
> > > +               }
> > > +  
> > Thanks for reporting this Denis, it definitely seems to be an oversight.
> > Would you mind adding a 'nfp_flower_cmsg_warn' here as well, so that
> > this case does not go undetected? Maybe something like "cannot
> > allocate memory for group processing" can work.
> 
> There's a checkpatch check against printing warnings on allocation
> failures. Kernel will complain loudly on OOM, anyway, there's no need
> for a local print.
Ah, thanks Jakub, I did not know that this is frowned upon. But I have
not thought about OOM - it would indeed not be a silent failure.

In that case I would be quite happy to add my Ack to v2 with the newline
comment addressed.
> -- 
> pw-bot: cr
diff mbox series

Patch

diff --git a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
index 88d6d992e7d0..8cc6cce73283 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
@@ -339,6 +339,11 @@  static void nfp_fl_lag_do_work(struct work_struct *work)
 		acti_netdevs = kmalloc_array(entry->slave_cnt,
 					     sizeof(*acti_netdevs), GFP_KERNEL);
 
+		if (!acti_netdevs) {
+			schedule_delayed_work(&lag->work, NFP_FL_LAG_DELAY);
+			continue;
+		}
+
 		/* Include sanity check in the loop. It may be that a bond has
 		 * changed between processing the last notification and the
 		 * work queue triggering. If the number of slaves has changed