From: Jakub Kicinski <kuba@kernel.org>
To: Shiming Cheng <shiming.cheng@mediatek.com>
Cc: <willemdebruijin.kernel@gmail.com>, <edumazet@google.com>,
<davem@davemloft.net>, <pabeni@redhat.com>,
<matthias.bgg@gmail.com>, <linux-kernel@vger.kernel.org>,
<netdev@vger.kernel.org>, <lena.wang@mediatek.com>
Subject: Re: [PATCH] net: fix udp gso skb_segment after pull from frag_list
Date: Thu, 22 May 2025 09:49:54 -0700 [thread overview]
Message-ID: <20250522094954.2f8090ce@kernel.org> (raw)
In-Reply-To: <20250522031835.4395-1-shiming.cheng@mediatek.com>
On Thu, 22 May 2025 11:18:04 +0800 Shiming Cheng wrote:
> Detect invalid geometry due to pull from frag_list, and pass to
> regular skb_segment. if only part of the fraglist payload is pulled
> into head_skb, When splitting packets in the skb_segment function,
> it will always cause exception as below.
>
> Valid SKB_GSO_FRAGLIST skbs
> - consist of two or more segments
> - the head_skb holds the protocol headers plus first gso_size
> - one or more frag_list skbs hold exactly one segment
> - all but the last must be gso_size
>
> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
> modify fraglist skbs, breaking these invariants.
>
> In extreme cases they pull one part of data into skb linear. For UDP,
> this causes three payloads with lengths of (11,11,10) bytes were
> pulled tail to become (12,10,10) bytes.
>
> When splitting packets in the skb_segment function, the first two
> packets of (11,11) bytes are split using skb_copy_bits. But when
> the last packet of 10 bytes is split, because hsize becomes nagative,
> it enters the skb_clone process instead of continuing to use
> skb_copy_bits. In fact, the data for skb_clone has already been
> copied into the second packet.
>
> when hsize < 0, the payload of the fraglist has already been copied
> (with skb_copy_bits), so there is no need to enter skb_clone to
> process this packet. Instead, continue using skb_copy_bits to process
> the next packet.
nit: please un-indent the text, you can keep the stack trace indented
but the commit message explanation should not be. And if you can
run the stack trace thru decode_stacktrace to add source code
references.
This patch seems to be causing regressions for SCTP, see:
https://lore.kernel.org/all/aC82JEehNShMjW8-@strlen.de/
If you send a v2 please make sure you add test cases to
net/core/net_test.c for both the geometry you're trying to fix,
and the geometry you got wrong in v1.
next prev parent reply other threads:[~2025-05-22 16:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 3:18 [PATCH] net: fix udp gso skb_segment after pull from frag_list Shiming Cheng
2025-05-22 16:49 ` Jakub Kicinski [this message]
2025-05-23 13:52 ` Willem de Bruijn
2025-05-23 14:04 ` Willem de Bruijn
-- strict thread matches above, loose matches on Subject: below --
2026-01-06 2:02 Shiming Cheng
2026-01-06 19:15 ` Willem de Bruijn
2026-01-07 2:57 ` Shiming Cheng (成诗明)
2026-01-07 16:00 ` Willem de Bruijn
2026-01-15 8:02 ` Shiming Cheng (成诗明)
2026-01-18 2:28 ` Willem de Bruijn
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=20250522094954.2f8090ce@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=lena.wang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shiming.cheng@mediatek.com \
--cc=willemdebruijin.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.