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 <[email protected]>
---
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;
+ }
+
/* 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
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 <[email protected]>
> ---
> 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
>
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.
--
pw-bot: cr
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