Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[kernel test robot]

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20250304141858.3392957-2-juny24602@gmail.com>
References: <20250304141858.3392957-2-juny24602@gmail.com>
TO: kwqcheii <juny24602@gmail.com>
TO: netdev@vger.kernel.org
CC: kwqcheii <juny24602@gmail.com>

Hi kwqcheii,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v6.14-rc5 next-20250306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/kwqcheii/sched-address-a-potential-NULL-pointer-dereference-in-the-GRED-scheduler/20250304-224144
base:   linus/master
patch link:    https://lore.kernel.org/r/20250304141858.3392957-2-juny24602%40gmail.com
patch subject: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.
:::::: branch date: 2 days ago
:::::: commit date: 2 days ago
config: riscv-randconfig-r072-20250306 (https://download.01.org/0day-ci/archive/20250307/202503070956.I8Z06FRE-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202503070956.I8Z06FRE-lkp@intel.com/

New smatch warnings:
net/sched/sch_gred.c:330 gred_offload() error: we previously assumed 'opt' could be null (see line 320)

Old smatch warnings:
net/sched/sch_gred.c:474 gred_change_table_def() warn: potential spectre issue 'table->tab' [w]

vim +/opt +330 net/sched/sch_gred.c

^1da177e4c3f41 Linus Torvalds 2005-04-16  310  
890d8d23ec3c9e Jakub Kicinski 2018-11-19  311  static void gred_offload(struct Qdisc *sch, enum tc_gred_command command)
890d8d23ec3c9e Jakub Kicinski 2018-11-19  312  {
890d8d23ec3c9e Jakub Kicinski 2018-11-19  313  	struct gred_sched *table = qdisc_priv(sch);
890d8d23ec3c9e Jakub Kicinski 2018-11-19  314  	struct net_device *dev = qdisc_dev(sch);
f25c0515c52137 Arnd Bergmann  2021-10-26  315  	struct tc_gred_qopt_offload *opt = table->opt;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  316  
890d8d23ec3c9e Jakub Kicinski 2018-11-19  317  	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
890d8d23ec3c9e Jakub Kicinski 2018-11-19  318  		return;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  319  
8eb926feee9101 kwqcheii       2025-03-04 @320  	if (opt) {
f25c0515c52137 Arnd Bergmann  2021-10-26  321  		memset(opt, 0, sizeof(*opt));
f25c0515c52137 Arnd Bergmann  2021-10-26  322  		opt->command = command;
f25c0515c52137 Arnd Bergmann  2021-10-26  323  		opt->handle = sch->handle;
f25c0515c52137 Arnd Bergmann  2021-10-26  324  		opt->parent = sch->parent;
8eb926feee9101 kwqcheii       2025-03-04  325  	}
f25c0515c52137 Arnd Bergmann  2021-10-26  326  
890d8d23ec3c9e Jakub Kicinski 2018-11-19  327  	if (command == TC_GRED_REPLACE) {
890d8d23ec3c9e Jakub Kicinski 2018-11-19  328  		unsigned int i;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  329  
f25c0515c52137 Arnd Bergmann  2021-10-26 @330  		opt->set.grio_on = gred_rio_mode(table);
f25c0515c52137 Arnd Bergmann  2021-10-26  331  		opt->set.wred_on = gred_wred_mode(table);
f25c0515c52137 Arnd Bergmann  2021-10-26  332  		opt->set.dp_cnt = table->DPs;
f25c0515c52137 Arnd Bergmann  2021-10-26  333  		opt->set.dp_def = table->def;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  334  
890d8d23ec3c9e Jakub Kicinski 2018-11-19  335  		for (i = 0; i < table->DPs; i++) {
890d8d23ec3c9e Jakub Kicinski 2018-11-19  336  			struct gred_sched_data *q = table->tab[i];
890d8d23ec3c9e Jakub Kicinski 2018-11-19  337  
890d8d23ec3c9e Jakub Kicinski 2018-11-19  338  			if (!q)
890d8d23ec3c9e Jakub Kicinski 2018-11-19  339  				continue;
f25c0515c52137 Arnd Bergmann  2021-10-26  340  			opt->set.tab[i].present = true;
f25c0515c52137 Arnd Bergmann  2021-10-26  341  			opt->set.tab[i].limit = q->limit;
f25c0515c52137 Arnd Bergmann  2021-10-26  342  			opt->set.tab[i].prio = q->prio;
f25c0515c52137 Arnd Bergmann  2021-10-26  343  			opt->set.tab[i].min = q->parms.qth_min >> q->parms.Wlog;
f25c0515c52137 Arnd Bergmann  2021-10-26  344  			opt->set.tab[i].max = q->parms.qth_max >> q->parms.Wlog;
f25c0515c52137 Arnd Bergmann  2021-10-26  345  			opt->set.tab[i].is_ecn = gred_use_ecn(q);
f25c0515c52137 Arnd Bergmann  2021-10-26  346  			opt->set.tab[i].is_harddrop = gred_use_harddrop(q);
f25c0515c52137 Arnd Bergmann  2021-10-26  347  			opt->set.tab[i].probability = q->parms.max_P;
f25c0515c52137 Arnd Bergmann  2021-10-26  348  			opt->set.tab[i].backlog = &q->backlog;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  349  		}
f25c0515c52137 Arnd Bergmann  2021-10-26  350  		opt->set.qstats = &sch->qstats;
890d8d23ec3c9e Jakub Kicinski 2018-11-19  351  	}
890d8d23ec3c9e Jakub Kicinski 2018-11-19  352  
f25c0515c52137 Arnd Bergmann  2021-10-26  353  	dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_GRED, opt);
890d8d23ec3c9e Jakub Kicinski 2018-11-19  354  }
890d8d23ec3c9e Jakub Kicinski 2018-11-19  355  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[Jun Yang]

On Wed, Mar 5, 2025 at 4:05 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> I think the whole gred_offload() should be skipped when table->opt ==
> NULL, espeically the last call of ->ndo_setup_tc(). Something like:

Thank you for your review. I have updated the part with my name.
I don't quite understand why the code would send a TC_SETUP_QDISC_GRED command during destroy. I haven't found the function that handles this command, so this part of the code should not produce side effects. Adding a check on the outer layer would indeed be safer. I have already modified this part of the patch.

[PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[kwqcheii]

If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path, invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash.
---
 net/sched/sch_gred.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index ab6234b4fcd5..fa643e5709bd 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -317,10 +317,12 @@ static void gred_offload(struct Qdisc *sch, enum tc_gred_command command)
 	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
 		return;
 
-	memset(opt, 0, sizeof(*opt));
-	opt->command = command;
-	opt->handle = sch->handle;
-	opt->parent = sch->parent;
+	if (opt) {
+		memset(opt, 0, sizeof(*opt));
+		opt->command = command;
+		opt->handle = sch->handle;
+		opt->parent = sch->parent;
+	}
 
 	if (command == TC_GRED_REPLACE) {
 		unsigned int i;
-- 
2.48.1

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[Cong Wang]

On Fri, Feb 28, 2025 at 12:04:19AM +0800, kwqcheii wrote:
> If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path, invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash.


Thanks for your patch.

Please add your Signed-off-by for your patch, which is a minimum
requirement here. You can check Linux kernel development process for
more details: https://docs.kernel.org/process/5.Posting.html#before-creating-patches

Also, ./scripts/checkpatch.pl could help you catch issues like this one,
it would save you and others a lot of time.

Lastly, if you saw a real crash, please include the kernel stack trace
in your patch description. There is a significant difference between a
real crash and a theoretical one.

Regards,
Cong

[PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[kwqcheii]

If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path,
invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive
a NULL pointer as input, potentially leading to a kernel crash.

Signed-off-by: kwqcheii <juny24602@gmail.com>
---
 net/sched/sch_gred.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index ab6234b4fcd5..fa643e5709bd 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -317,10 +317,12 @@ static void gred_offload(struct Qdisc *sch, enum tc_gred_command command)
 	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
 		return;
 
-	memset(opt, 0, sizeof(*opt));
-	opt->command = command;
-	opt->handle = sch->handle;
-	opt->parent = sch->parent;
+	if (opt) {
+		memset(opt, 0, sizeof(*opt));
+		opt->command = command;
+		opt->handle = sch->handle;
+		opt->parent = sch->parent;
+	}
 
 	if (command == TC_GRED_REPLACE) {
 		unsigned int i;
-- 
2.48.1

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[Cong Wang]

On Tue, Mar 04, 2025 at 10:18:59PM +0800, kwqcheii wrote:
> If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path,
> invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive
> a NULL pointer as input, potentially leading to a kernel crash.
> 
> Signed-off-by: kwqcheii <juny24602@gmail.com>

Please use your real name for Signed-off-by.

> ---
>  net/sched/sch_gred.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
> index ab6234b4fcd5..fa643e5709bd 100644
> --- a/net/sched/sch_gred.c
> +++ b/net/sched/sch_gred.c
> @@ -317,10 +317,12 @@ static void gred_offload(struct Qdisc *sch, enum tc_gred_command command)
>  	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
>  		return;
>  
> -	memset(opt, 0, sizeof(*opt));
> -	opt->command = command;
> -	opt->handle = sch->handle;
> -	opt->parent = sch->parent;
> +	if (opt) {
> +		memset(opt, 0, sizeof(*opt));
> +		opt->command = command;
> +		opt->handle = sch->handle;
> +		opt->parent = sch->parent;
> +	}

I think the whole gred_offload() should be skipped when table->opt ==
NULL, espeically the last call of ->ndo_setup_tc(). Something like:

diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index ab6234b4fcd5..532fde548b88 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -913,7 +913,8 @@ static void gred_destroy(struct Qdisc *sch)
        for (i = 0; i < table->DPs; i++)
                gred_destroy_vq(table->tab[i]);

-       gred_offload(sch, TC_GRED_DESTROY);
+       if (table->opt)
+               gred_offload(sch, TC_GRED_DESTROY);
        kfree(table->opt);
 }

What do you think?

Thanks.

[PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[Jun Yang]

If kzalloc in gred_init returns a NULL pointer, the code follows the
error handling path, invoking gred_destroy. This, in turn, calls
gred_offload, where memset could receive a NULL pointer as input,
potentially leading to a kernel crash.

Signed-off-by: Jun Yang <juny24602@gmail.com>
---
 net/sched/sch_gred.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index ab6234b4fcd5..532fde548b88 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -913,7 +913,8 @@ static void gred_destroy(struct Qdisc *sch)
 	for (i = 0; i < table->DPs; i++)
 		gred_destroy_vq(table->tab[i]);
 
-	gred_offload(sch, TC_GRED_DESTROY);
+	if (table->opt)
+		gred_offload(sch, TC_GRED_DESTROY);
 	kfree(table->opt);
 }
 
-- 
2.48.1

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[Cong Wang]

On Wed, Mar 05, 2025 at 11:44:10PM +0800, Jun Yang wrote:
> If kzalloc in gred_init returns a NULL pointer, the code follows the
> error handling path, invoking gred_destroy. This, in turn, calls
> gred_offload, where memset could receive a NULL pointer as input,
> potentially leading to a kernel crash.
> 
> Signed-off-by: Jun Yang <juny24602@gmail.com>

When table->opt is NULL in gred_init(), gred_change_table_def() is not
called yet, so it is not necessary to call ->ndo_setup_tc() in
gred_offload().

Fixes: f25c0515c521 ("net: sched: gred: dynamically allocate tc_gred_qopt_offload")
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>

Thanks!

Re: [PATCH] sched: address a potential NULL pointer dereference in the GRED scheduler.

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  5 Mar 2025 23:44:10 +0800 you wrote:
> If kzalloc in gred_init returns a NULL pointer, the code follows the
> error handling path, invoking gred_destroy. This, in turn, calls
> gred_offload, where memset could receive a NULL pointer as input,
> potentially leading to a kernel crash.
> 
> Signed-off-by: Jun Yang <juny24602@gmail.com>
> 
> [...]

Here is the summary with links:
  - sched: address a potential NULL pointer dereference in the GRED scheduler.
    https://git.kernel.org/netdev/net/c/115ef44a9822

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html