[PATCH] net: gro: avoid parsing headers from shared fragments

[PATCH] net: gro: avoid parsing headers from shared fragments

[Kyle Zeng]

When an skb has an empty linear head, skb_gro_reset_offset() can expose
the first page fragment directly to GRO header parsers. For a
SKBFL_SHARED_FRAG skb, those bytes may still be writable through a file
mapping. Headers validated during receive can therefore differ from the
headers later copied into the linear head and used during completion.

For example, changing an IPv6 destination-options length between the
short and full header fetches in ipv6_gro_pull_exthdrs() can make
ipv6_gro_complete() pass an out-of-bounds offset to udp6_gro_complete().
This is reachable with an ordinary TCP GSO skb containing spliced file
data, without an skb zerocopy destructor or a second GRO packet.

Keep the direct-fragment fast path disabled for skbs with externally
writable fragments. With an empty linear head, frag0_len remains zero,
so skb_gro_header_slow() pulls each required header into the linear head
before it is inspected. Subsequent pulls preserve the already validated
prefix. This covers both gro_receive_skb() and napi_gro_frags() while
leaving the existing linear-head and private-fragment fast paths alone.

Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
I have a reproducer for this issue and can share via DM

 net/core/gro.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/gro.c b/net/core/gro.c
index 1b033855a20d..d6cf2d497934 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -413,7 +413,8 @@ static inline void skb_gro_reset_offset(struct sk_buff *skb, u32 nhoff)
 	headlen = skb_headlen(skb);
 	NAPI_GRO_CB(skb)->frag0 = skb->data;
 	NAPI_GRO_CB(skb)->frag0_len = headlen;
-	if (headlen)
+	/* Shared fragments must be pulled into the linear head before parsing. */
+	if (headlen || skb_has_shared_frag(skb))
 		return;
 
 	pinfo = skb_shinfo(skb);

base-commit: d89e1d186ec9271bf78e62771779e9fc03bf0fc3
-- 
2.56.0

Re: [PATCH] net: gro: avoid parsing headers from shared fragments

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH] net: gro: avoid parsing headers from shared fragments

[Eric Dumazet]

Le ven. 30 oct. 2026 à 05:22, Kyle Zeng <kylebot@openai.com> a écrit :
>
> When an skb has an empty linear head, skb_gro_reset_offset() can expose
> the first page fragment directly to GRO header parsers. For a
> SKBFL_SHARED_FRAG skb, those bytes may still be writable through a file
> mapping. Headers validated during receive can therefore differ from the
> headers later copied into the linear head and used during completion.
>
> For example, changing an IPv6 destination-options length between the
> short and full header fetches in ipv6_gro_pull_exthdrs() can make
> ipv6_gro_complete() pass an out-of-bounds offset to udp6_gro_complete().
> This is reachable with an ordinary TCP GSO skb containing spliced file
> data, without an skb zerocopy destructor or a second GRO packet.

"ordinary TCP GSO skb" ???

I do not see how a TCP GSO skb reaches skb_gro_reset_offset() with
skb_headlen() == 0 : TCP always builds its headers in skb->head.

My guess is that you need a decap step first (gro_cells after a tunnel
pulled the outer headers), so that the inner headers come from spliced
pages and start at frags[0].

Please describe the exact path in the changelog, and send me the
reproducer privately.


>
> Keep the direct-fragment fast path disabled for skbs with externally
> writable fragments. With an empty linear head, frag0_len remains zero,
> so skb_gro_header_slow() pulls each required header into the linear head
> before it is inspected. Subsequent pulls preserve the already validated
> prefix. This covers both gro_receive_skb() and napi_gro_frags() while
> leaving the existing linear-head and private-fragment fast paths alone.
>
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
> I have a reproducer for this issue and can share via DM

The fix itself looks fine to me, but for v2 please:

- Target the net tree ([PATCH net]).

- Add a Fixes: tag. This is requested for net patches.

- Tell us how the bug was found (tool, LLM, manual audit...), as the
  netdev bot asked.

Thanks.