netdev - Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <b4bfec13-34a1-4320-bac9-338e909f15d5@app.fastmail.com>
Date: Wed, 04 Feb 2026 14:47:55 +0200
From: "Alice Mikityanska" <alice.kernel@...tmail.im>
To: "Gal Pressman" <gal@...dia.com>
Cc: "Willem de Bruijn" <willemdebruijn.kernel@...il.com>,
 "Igor Russkikh" <irusskikh@...vell.com>,
 "Boris Pismenny" <borisp@...dia.com>, "Saeed Mahameed" <saeedm@...dia.com>,
 "Leon Romanovsky" <leon@...nel.org>, "Tariq Toukan" <tariqt@...dia.com>,
 "Mark Bloch" <mbloch@...dia.com>, "David Ahern" <dsahern@...nel.org>,
 "Simon Horman" <horms@...nel.org>, "Alexander Duyck" <alexanderduyck@...com>,
 linux-rdma@...r.kernel.org, "Dragos Tatulea" <dtatulea@...dia.com>,
 "David S. Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, "Andrew Lunn" <andrew+netdev@...n.ch>,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for
 GSO_PARTIAL

On Tue, Feb 3, 2026, at 15:51, Gal Pressman wrote:
> Hello Alice,
>
> On 03/02/2026 14:20, Alice Mikityanska wrote:
>>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>>> index 19d0b5b09ffa..89e0b48b60ae 100644
>>>> --- a/net/ipv4/udp_offload.c
>>>> +++ b/net/ipv4/udp_offload.c
>>>> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>>  	struct sock *sk = gso_skb->sk;
>>>>  	unsigned int sum_truesize = 0;
>>>>  	struct sk_buff *segs, *seg;
>>>> +	__be16 newlen, msslen;
>>>>  	struct udphdr *uh;
>>>>  	unsigned int mss;
>>>>  	bool copy_dtor;
>>>>  	__sum16 check;
>>>> -	__be16 newlen;
>>>>  	int ret = 0;
>>>>  
>>>>  	mss = skb_shinfo(gso_skb)->gso_size;
>>>> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>>  		return segs;
>>>>  	}
>>>>  
>>>> +	msslen = htons(sizeof(*uh) + mss);
>>>> +
>>>>  	/* GSO partial and frag_list segmentation only requires splitting
>>>>  	 * the frame into an MSS multiple and possibly a remainder, both
>>>>  	 * cases return a GSO skb. So update the mss now.
>> 
>> What about the frag_list case? The comment says it would be a GSO SKB
>> too (as I understand frag_list, it would be a linked list of SKBs
>> forming one single packet). Is it appropriate to set UDP len = MSS in
>> this case too? I'm not sure which code reads UDP len afterwards, I
>> couldn't find any, so maybe its value doesn't matter at all (except for
>> hardware, which this patch aims for).
>
> The behavior should be the same, the structure of the skbs the packet
> originated from shouldn't affect this change.
>
>> 
>> Is it possible that this GSO_PARTIAL or frag_list packet shows up in
>> tcpdump with UDP len set like this? E.g., if the GSO_PARTIAL
>> segmentation happens before entering a veth pipe, and tcpdump listens on
>> the other end? If so, tcpdump could fail to parse such a packet.
>
> You will see a large packet with a single MSS value in tcpdump, and
> that's consistent with the behavior we have for UDP tunnels.
> tcpdump parses the packet without any issues.

Yeah, just checked tcpdump: it shows the full payload, regardless of UDP
length and IP length in the headers. Sounds good to me, thanks for the
clarifications!

>> 
>> I haven't tried to reproduce any of these yet; I decided to ask first
>> because you have more context. I'll appreciate if you can give me a clue
>> whether my concerns are valid or not.
>> 
>> Other than that, I think the patch could be made simpler, if you just
>> drop mss *= gso_segs below, and stick to newlen, which would be equal to
>> msslen (now unneeded), and newlen and mss are not used anywhere else.
>> I'll include this simplification in my next series, if you don't mind.
>
> Feel free :).