From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Shiming Cheng <shiming.cheng@mediatek.com>,
netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com, willemb@google.com,
imv4bel@gmail.com, alice@isovalent.com,
eilaimemedsnaimel@gmail.com, sd@queasysnail.net,
steffen.klassert@secunet.com
Cc: lena.wang@mediatek.com, stable@vger.kernel.org,
Shiming Cheng <shiming.cheng@mediatek.com>
Subject: Re: [PATCH v2] Subject: [PATCH] net: gro: fix double aggregation of flush-marked skbs
Date: Tue, 30 Jun 2026 21:54:37 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.257d168c38ada@gmail.com> (raw)
In-Reply-To: <20260626084451.27699-1-shiming.cheng@mediatek.com>
Thanks for the fix.
There is something weird with your subject lines:
[PATCH v2] Subject: [PATCH] net:
> The new skb_gro_receive_list() function is missing a critical safety check
> present in the legacy skb_gro_receive() path.
, as of commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a
GSO packet.").
Please add a comment referring to this commit, as it well explains the
need for the flush.
> Specifically, it does not
> validate NAPI_GRO_CB(skb)->flush before allowing packet aggregation.
> This allows already-GRO'd packets with existing frag_list to be
> re-aggregated into a new GRO session, corrupting the frag_list chain
> structure. When skb_segment() attempts to unpack these malformed packets,
> it encounters invalid state and triggers a kernel panic.
>
> Scenario (Tethering/Device forwarding):
> 1. Driver: Generated aggregated packet P1 via LRO with frag_list
> 2. Dev A: Receives aggregated fraglist packet and flush flag set
> 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called
> 4. Missing flush check allows re-aggregation despite flush flag
> 5. Frag_list chain becomes corrupted (loops or dangling refs)
> 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list
>
> Root cause in skb_segment():
> The check at line ~4891:
> if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) &&
> (skb_headlen(list_skb) == len || sg)) {
>
> When frag_list is corrupted by double aggregation, when list_skb is
> a NULL pointer from skb->next, skb_headlen(list_skb) dereference
> NULL/corrupted pointers occurs.
>
> Call Trace:
> skb_headlen(NULL skb)
> skb_segment
> tcp_gso_segment
> tcp4_gso_segment
> inet_gso_segment
> skb_mac_gso_segment
> __skb_gso_segment
> skb_gso_segment
> validate_xmit_skb
> validate_xmit_skb_list
> sch_direct_xmit
> qdisc_restart
> __qdisc_run
> qdisc_run
> net_tx_action
>
> Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in
> skb_gro_receive_list(), matching the defensive programming pattern of
> skb_gro_receive().
>
> Fixes: 9dc2c3cd6c11 ("net: add fraglist GRO/GSO support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
> ---
> 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 35f2f708f010..076247c1e662 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -229,7 +229,8 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
>
> int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
> {
> - if (unlikely(p->len + skb->len >= 65536))
> + if (unlikely(p->len + skb->len >= 65536 ||
> + NAPI_GRO_CB(skb)->flush))
> return -E2BIG;
>
> if (!pskb_may_pull(skb, skb_gro_offset(skb))) {
prev parent reply other threads:[~2026-07-01 1:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 8:44 [PATCH v2] Subject: [PATCH] net: gro: fix double aggregation of flush-marked skbs Shiming Cheng
2026-07-01 1:54 ` Willem de Bruijn [this message]
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=willemdebruijn.kernel.257d168c38ada@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=alice@isovalent.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eilaimemedsnaimel@gmail.com \
--cc=horms@kernel.org \
--cc=imv4bel@gmail.com \
--cc=kuba@kernel.org \
--cc=lena.wang@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=shiming.cheng@mediatek.com \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.