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: <ae132d54-6fb1-40fb-b172-d5683a872ae9@nvidia.com>
Date: Tue, 3 Feb 2026 15:51:21 +0200
From: Gal Pressman <gal@...dia.com>
To: Alice Mikityanska <alice@...tmail.im>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: 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

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.

> 
> 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 :).