linux-kernel - Re: [PATCH net] vmxnet3: correctly report gso type for UDP tunnels

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <71d0fbf8-00f7-4e0b-819d-d0b6efb01f03@redhat.com>
Date: Mon, 19 May 2025 09:29:58 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Ronak Doshi <ronak.doshi@...adcom.com>
Cc: netdev@...r.kernel.org, Guolin Yang <guolin.yang@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] vmxnet3: correctly report gso type for UDP tunnels

On 5/15/25 4:02 PM, Jakub Kicinski wrote:
> On Tue, 13 May 2025 21:05:02 +0000 Ronak Doshi wrote:
>> +				skb->encapsulation = 1;
>>  			}
>>  			WARN_ON_ONCE(!(gdesc->rcd.tcp || gdesc->rcd.udp) &&
>>  				     !(le32_to_cpu(gdesc->dword[0]) &
>> @@ -1465,6 +1466,7 @@ vmxnet3_rx_csum(struct vmxnet3_adapter *adapter,
>>  			if ((le32_to_cpu(gdesc->dword[0]) &
>>  				     (1UL << VMXNET3_RCD_HDR_INNER_SHIFT))) {
>>  				skb->csum_level = 1;
>> +				skb->encapsulation = 1;
> 
> IIRC ->encapsulation means that ->inner.. fields are valid, no?
> And I don't see you setting any of these.
> 
> Paolo, please keep me honest, IIUC you have very recent and very
> relevant experience with virtio.

Yes. Specifically the GSO code expect the inner headers to be set,
otherwise the segmentation will yield quite wrong results.

Note that reproducing the issue requires a quite specific setup, i.e.
bridging (or tc redirecting) the ingress traffic from an
UDP-tunnel-HW-GRO enabled device into an egress device not supporting
tx-udp_tnl-segmentation.

If otherwise the traffic goes into the UDP tunnel rx path, such
processing will set the needed field correctly and no issue could/should
be observed AFAICS.

@Ronak: I think the problem pre-exists this specific patch, but since
you are fixing the relevant offload, I think it should be better to
address the problem now.

Thanks,

Paolo