From: Simon Horman <horms@kernel.org>
To: alice.kernel@fastmail.im
Cc: Simon Horman <horms@kernel.org>,
daniel@iogearbox.net, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, lucien.xin@gmail.com,
willemdebruijn.kernel@gmail.com, willemb@google.com,
dsahern@kernel.org, razor@blackwall.org, shuah@kernel.org,
stfomichev@gmail.com, andrew+netdev@lunn.ch, fw@strlen.de,
netdev@vger.kernel.org, alice@isovalent.com
Subject: Re: [PATCH net-next v9 2/9] net: Enable BIG TCP with partial GSO
Date: Thu, 16 Jul 2026 15:47:25 +0100 [thread overview]
Message-ID: <20260716144724.333095-2-horms@kernel.org> (raw)
In-Reply-To: <20260710134242.216538-3-alice.kernel@fastmail.im>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
--- Patch [2]: [PATCH net-next v9 2/9] net: Enable BIG TCP with partial GSO ---
commit b8199f77774400021642eb53bd60ec1a062a54ef
Author: Alice Mikityanska <alice@isovalent.com>
net: Enable BIG TCP with partial GSO
This commit removes the 65534-byte clamp on segment length in skb_segment
for partial GSO. It stores the gso_by_frags flag early to allow BIG TCP
packets to use larger lengths without accidental resegmentation.
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 18dabb4e9cfa0..6ae4c2b205f2e 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
[ ... ]
> @@ -4852,9 +4853,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> /* GSO partial only requires that we trim off any excess that
> * doesn't fit into an MSS sized block, so take care of that
> * now.
> - * Cap len to not accidentally hit GSO_BY_FRAGS.
> */
> - partial_segs = min(len, GSO_BY_FRAGS - 1) / mss;
> + partial_segs = len / mss;
[Severity: High]
When removing the clamp on partial GSO segments, mss is scaled up without any
upper bound. For BIG TCP packets, could this construct segments that exceed
MAX_SKB_FRAGS?
If a 512KB packet is passed to skb_segment() for partial GSO, mss is scaled
up to the full packet length. When attempting to build this single large
segment by flattening the frag_list into a new frags array, it appears it
would hit the fragment limit and abort:
net/core/skbuff.c:skb_segment() {
...
if (unlikely(skb_shinfo(nskb)->nr_frags >=
MAX_SKB_FRAGS)) {
net_warn_ratelimited(
"skb_segment: too many frags: %u %u\n",
pos, mss);
err = -EINVAL;
goto err;
}
...
}
Does this deterministically drop BIG TCP traffic over tunnels that require
partial GSO?
[Severity: Medium]
Can the partial_segs calculation exceed 65535 for malicious inputs and cause
a 16-bit truncation?
If a crafted packet with a very small gso_size (for example, mss=1 via an
untrusted packet socket) and a large payload is segmented, len / mss could
produce a value greater than 65535.
When this 32-bit value is later assigned to the 16-bit field in skb_segment():
net/core/skbuff.c:skb_segment() {
...
skb_shinfo(iter)->gso_segs = partial_segs;
...
}
Could this silent truncation corrupt hardware engine programming or Byte Queue
Limits?
> if (partial_segs > 1)
> mss *= partial_segs;
> else
[ ... ]
next prev parent reply other threads:[~2026-07-16 14:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 13:42 [PATCH net-next v9 0/9] BIG TCP for UDP tunnels Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 1/9] net: Use helpers to get/set UDP len tree-wide Alice Mikityanska
2026-07-16 14:46 ` Simon Horman
2026-07-16 15:18 ` Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 2/9] net: Enable BIG TCP with partial GSO Alice Mikityanska
2026-07-16 14:47 ` Simon Horman [this message]
2026-07-16 16:28 ` Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 3/9] udp: Support BIG TCP GSO packets where they can occur Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536 Alice Mikityanska
2026-07-16 14:47 ` Simon Horman
2026-07-16 17:04 ` Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 5/9] udp: Validate UDP length in udp_gro_receive Alice Mikityanska
2026-07-16 14:48 ` Simon Horman
2026-07-16 18:32 ` Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 6/9] udp: Set length in UDP header to 0 for big GSO packets Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 7/9] vxlan: Enable BIG TCP packets Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 8/9] geneve: " Alice Mikityanska
2026-07-16 14:48 ` Simon Horman
2026-07-16 18:45 ` Alice Mikityanska
2026-07-10 13:42 ` [PATCH net-next v9 9/9] selftests: net: Add a test for BIG TCP in UDP tunnels Alice Mikityanska
2026-07-11 9:47 ` [PATCH net-next v9 0/9] BIG TCP for " Nikolay Aleksandrov
2026-07-15 6:11 ` zebang.li
[not found] ` <(raw)>
2026-07-15 9:06 ` Alice Mikityanska
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=20260716144724.333095-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=alice.kernel@fastmail.im \
--cc=alice@isovalent.com \
--cc=andrew+netdev@lunn.ch \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kuba@kernel.org \
--cc=lucien.xin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=shuah@kernel.org \
--cc=stfomichev@gmail.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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.