[PATCH] gro: check returned skb of napi_frags_skb() against NULL

[PATCH] gro: check returned skb of napi_frags_skb() against NULL

[Kaiyu Zhang]

Some rogue network adapter and their driver pass bad skbs to GRO.
napi_frags_skb() detects this, drops these bad skbs, and return NULL
to napi_gro_frags(), which does not check returned skb against NULL
and access it. This results in a kernel crash.

A better approach to address these bad skbs would be to issue some
warnings and drop them, which napi_frags_skb() already does, and
move on without crashing the kernel.

Signed-off-by: Kaiyu Zhang <squirrel.prog@gmail.com>
---
 net/core/gro.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/core/gro.c b/net/core/gro.c
index 0759277dc..18d92016b 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -731,6 +731,9 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
 	gro_result_t ret;
 	struct sk_buff *skb = napi_frags_skb(napi);
 
+	if (unlikely(!skb))
+		return GRO_CONSUMED;
+
 	trace_napi_gro_frags_entry(skb);
 
 	ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
-- 
2.34.1

Re: [PATCH] gro: check returned skb of napi_frags_skb() against NULL

[Eric Dumazet]

On Thu, Jul 6, 2023 at 3:08 PM Kaiyu Zhang <squirrel.prog@gmail.com> wrote:
>
> Some rogue network adapter and their driver pass bad skbs to GRO.
> napi_frags_skb() detects this, drops these bad skbs, and return NULL
> to napi_gro_frags(), which does not check returned skb against NULL
> and access it. This results in a kernel crash.
>
> A better approach to address these bad skbs would be to issue some
> warnings and drop them, which napi_frags_skb() already does, and
> move on without crashing the kernel.
>

Certainly not.

We are not going to try to be nice to buggy drivers.

Please fix the "rogue network adapter" instead.

Re: [PATCH] gro: check returned skb of napi_frags_skb() against NULL

[Eric Dumazet]

On Thu, Jul 6, 2023 at 4:35 PM Kaiyu Zhang <squirrel.prog@gmail.com> wrote:
>
> Yes the network adapter needs to be fixed for passing invalid packets to GRO. And a message like "dropping impossible skb" should be indicative enough for developers to do so.
>
> And yet I propose this patch because an immediate system crash caused by NULL pointer access after the above warning message is a bit more difficult to analyse on some test bed where developers have to restore kernel messages after a reboot .
>
> Furthermore, the adapter I'm working with is capable of receiving very small packets (1 or 2 bytes). They insist this is a feature rather than a bug. I can, and I will check packet length before passing them to GRO, for this particular adapter. But maybe a non-crash warning in general might be helpful to other developers who will face the same problem and spare them some effort on debugging.

1 or 2 bytes would still be stored in an skb, right ?

GRO is already very slow, we do not want to make it even slower so
that some developers can save time.
A kernel crash would point to the NULL deref just fine.

If we continue this path, we will soon add "if (!skb) be_kind" to all
functions accepting an skb as a parameter,
then everything else...