netdev - mlx5 and gre tunneling

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

Message-ID: <c42961cb-50b9-4a9a-bd43-87fe48d88d29@akamai.com>
Date: Mon, 8 Apr 2024 09:41:36 -0400
From: Jason Baron <jbaron@...mai.com>
To: saeedm@...dia.com
Cc: netdev@...r.kernel.org
Subject: mlx5 and gre tunneling

Hi,

I recently found an issue where if I send udp traffic in a GRE tunnel 
over a mellanox 5 NIC where tx-gre-segmentation is enbalbed on the NIC, 
then packets on the receive side are corrupted to a point that they are 
never passed up to the user receive socket. I took a look at the 
received traffic and the inner ip headers appear corrupted as well as 
the payloads. This reproduces every time for me on both AMD and Intel 
based x86 systems.

The reproducer is quite simple. For example something like this will work:

https://github.com/rom1v/udp-segmentation

It just needs to be modified to actually pass the traffic through the 
NIC (ie not localhost). As long as the original UDP packet needs to be 
segmented I see the corruption. That is if it all fits in one packet, I 
don't see the corruption. Turning off tx-gre-segmentation on the 
mellanox NIC makes the problem go away (as it gets segmented first in 
software). Also, I've successfully run this test with other NICs. So 
this appears to be something specific to the Mellanox NIC.

Here's an example one that fails, with the latest upstream (6.8) kernel, 
for example:

driver: mlx5_core
version: 6.8.0+
firmware-version: 16.35.3502 (MT_0000000242)

Let me know if I can fill in any more details.

Thanks!

-Jason