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

[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

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.