From: Eric Dumazet <edumazet@kernel.org>
To: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
AutonomousCodeSecurity@microsoft.com, netdev@vger.kernel.org,
edumazet@kernel.org, Taesoo Kim <tsgatesv@gmail.com>,
Cen Zhang <cenzhang@linux.microsoft.com>
Subject: [PATCH net 2/2] net: gro: invalidate frag0 after a pull
Date: Wed, 28 Oct 2026 15:13:25 +0100 [thread overview]
Message-ID: <20261028141325.2103814-3-edumazet@kernel.org> (raw)
In-Reply-To: <20261028141325.2103814-1-edumazet@kernel.org>
Since commit bd56a29c7a4e ("net: gro: change skb_gro_network_header()"),
skb_gro_header_slow() no longer invalidates NAPI_GRO_CB(skb)->frag0
after pskb_may_pull(). skb_gro_may_pull() keeps comparing against the
frag0_len value set in skb_gro_reset_offset(), assuming that after a
slow pull, all later accesses are beyond frag0_len.
This is not true:
- udp4_gro_receive() and udp6_gro_receive() read the network header
with skb_gro_network_header() after udp_gro_udphdr() pulled the
UDP header.
- vxlan_gro_receive() calls skb_gro_remcsum_cleanup() at a lower
offset after the inner handlers pulled their headers.
- skb_gro_remcsum_process() can pull beyond the inner Ethernet header
before eth_gro_receive() reads it.
- napi_frags_skb() calls __skb_pull(skb, ETH_HLEN) after a slow pull,
so frag0 still points to the Ethernet header.
If the pull consumed the first page fragment, __skb_pull_tail() released
it. If the head had to grow, pskb_expand_head() freed the old one.
These reads, and the 2-byte write in skb_gro_remcsum_cleanup(), then
access memory the skb no longer holds a reference on.
esp4_gro_receive(), esp6_gro_receive(), skb_gro_receive_list() and
udp_gro_receive_segment() also pull directly and never invalidated
frag0.
Add skb_gro_frag0_invalidate(), which only clears frag0_len, and call
it after each of these pulls. This is a single store in the slow path,
and frag0 stays non NULL, so skb_gro_network_header() does not need
a NULL test.
Fixes: bd56a29c7a4e ("net: gro: change skb_gro_network_header()")
Reported-by: Taesoo Kim <tsgatesv@gmail.com>
Reported-by: Cen Zhang <cenzhang@linux.microsoft.com>
Tested-by: Cen Zhang <cenzhang@linux.microsoft.com>
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
---
include/net/gro.h | 10 ++++++++++
net/core/gro.c | 1 +
net/ipv4/esp4_offload.c | 1 +
net/ipv4/udp_offload.c | 1 +
net/ipv6/esp6_offload.c | 1 +
5 files changed, 14 insertions(+)
diff --git a/include/net/gro.h b/include/net/gro.h
index b560e866683b03314b3e80a887ac4467d1a5acb9..78373e9caf68b6acefcd976ed7192ec5e44db2b9 100644
--- a/include/net/gro.h
+++ b/include/net/gro.h
@@ -160,12 +160,22 @@ static inline bool skb_gro_may_pull(const struct sk_buff *skb,
return likely(hlen <= NAPI_GRO_CB(skb)->frag0_len);
}
+/* A pull can release the page fragment frag0 points to, or reallocate
+ * skb->head. Make sure later skb_gro_header() and skb_gro_network_header()
+ * calls no longer use frag0.
+ */
+static inline void skb_gro_frag0_invalidate(struct sk_buff *skb)
+{
+ NAPI_GRO_CB(skb)->frag0_len = 0;
+}
+
static inline void *skb_gro_header_slow(struct sk_buff *skb, unsigned int hlen,
unsigned int offset)
{
if (!pskb_may_pull(skb, hlen))
return NULL;
+ skb_gro_frag0_invalidate(skb);
return skb->data + offset;
}
diff --git a/net/core/gro.c b/net/core/gro.c
index ff828a3dce3ca649e149a840bd6e3dfd9ddaf0c4..2fe1bbe49a082873a700d36f7a10570f0954526e 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -242,6 +242,7 @@ int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
NAPI_GRO_CB(skb)->flush = 1;
return -ENOMEM;
}
+ skb_gro_frag0_invalidate(skb);
if (NAPI_GRO_CB(p)->last == p)
skb_shinfo(p)->frag_list = skb;
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index abd77162f5e75ec01d5e66693f20a80a78af9e50..dea34411e77f6cf1302315e665df003e4d1130a6 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -39,6 +39,7 @@ static struct sk_buff *esp4_gro_receive(struct list_head *head,
if (!pskb_pull(skb, offset))
return NULL;
+ skb_gro_frag0_invalidate(skb);
if (xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq) != 0)
goto out;
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index cf07c3c6611a22c29b57a72420f2f940609f5e9a..62c44c450d78c9c2b9ea38d953376026fd2aa4e7 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -747,6 +747,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
NAPI_GRO_CB(skb)->flush = 1;
return NULL;
}
+ skb_gro_frag0_invalidate(skb);
if ((skb->ip_summed != p->ip_summed) ||
(skb->csum_level != p->csum_level)) {
NAPI_GRO_CB(skb)->flush = 1;
diff --git a/net/ipv6/esp6_offload.c b/net/ipv6/esp6_offload.c
index 22895521a57d09acfe091927f20188764f33f91b..674e66541d9f914bf788a148bceea51c1067f541 100644
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -66,6 +66,7 @@ static struct sk_buff *esp6_gro_receive(struct list_head *head,
if (!pskb_pull(skb, offset))
return NULL;
+ skb_gro_frag0_invalidate(skb);
if (xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq) != 0)
goto out;
--
2.53.0
next prev parent reply other threads:[~2026-10-28 14:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 14:13 [PATCH net 0/2] net: gro: fix frag0 and remcsum handling Eric Dumazet
2026-10-28 14:13 ` [PATCH net 1/2] net: gro: do not undo remote checksum offload on merged packets Eric Dumazet
2026-10-29 8:04 ` Paolo Abeni
2026-10-29 14:14 ` Willem de Bruijn
2026-10-29 14:15 ` netdev-bot+sashiko
2026-10-28 14:13 ` Eric Dumazet [this message]
2026-10-29 14:15 ` [PATCH net 2/2] net: gro: invalidate frag0 after a pull netdev-bot+sashiko
2026-10-28 14:15 ` [PATCH net 0/2] net: gro: fix frag0 and remcsum handling netdev-bot+sinfo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028141325.2103814-3-edumazet@kernel.org \
--to=edumazet@kernel.org \
--cc=AutonomousCodeSecurity@microsoft.com \
--cc=cenzhang@linux.microsoft.com \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
--cc=tsgatesv@gmail.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox