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 <[email protected]>
---
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
On Thu, Jul 6, 2023 at 3:08 PM Kaiyu Zhang <[email protected]> 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.
On Thu, Jul 6, 2023 at 4:35 PM Kaiyu Zhang <[email protected]> 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...