From: Gabriel Goller <g.goller@proxmox.com>
To: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Boris Sukholitko <boris.sukholitko@broadcom.com>,
Aaron Conole <aconole@redhat.com>,
Eelco Chaudron <echaudro@redhat.com>,
Ilya Maximets <i.maximets@ovn.org>,
Shuah Khan <shuah@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dev@openvswitch.org, linux-kselftest@vger.kernel.org,
Gabriel Goller <g.goller@proxmox.com>
Subject: [PATCH RFC net 0/3] net: fix stacked VLAN header corruption in TX offloads and OVS
Date: Wed, 11 Nov 2026 18:37:48 +0100 [thread overview]
Message-ID: <20261111-net_restore_the-v1-0-6aaeffa601c9@proxmox.com> (raw)
Since commit 938863727076 ("tc: adjust network header after 2nd vlan
push"), a second VLAN push leaves network_header pointing to the
in-band VLAN header. The igb driver TSO and OVS IP set actions still
expect the L3 header, so they write to the VLAN header and corrupt
the packet. Patch 1 restores the L3 header in validate_xmit_skb() for
CHECKSUM_PARTIAL packets, which covers packets tagged by tc or BPF.
Patch 2 restores it in OVS right after the push, before later actions
run. Patch 3 adds a KUnit test. tc classification after a push keeps
working.
The kernel uses two conventions for skb->network_header when a packet
carries an in-band VLAN tag:
* network_header points at the L3 header
* network_header points at the in-band VLAN header
Since commit 938863727076 ("tc: adjust network header after 2nd vlan
push"), skb_vlan_push() uses the second convention when it pushes a
second tag. The flow dissector, and so tc flower, needs that layout to
classify the packet after the push. Drivers doing TSO or checksum
offload expect the first one. vlan_features_check() clears TSO for
multi-tagged packets, so most drivers fall back to software GSO, which
finds the L3 header itself. igb keeps TSO for these packets and reads
the IP header at skb->network_header, so it builds the TSO context from
the VLAN header and corrupts the packet. OVS set actions after a second
push write to the wrong header in the same way.
Which convention should a packet with in-band VLAN tags follow? This
series keeps the tc layout, converts to L3 in validate_xmit_skb() for
CHECKSUM_PARTIAL packets, and restores L3 right after the push in OVS.
If L3 should hold everywhere instead, the flow dissector would need to
find in-band tags from mac_len, and skb_vlan_push() could go back to
its old behavior.
We hit this in production with VLAN-tagged traffic forwarded by OVS out
of an igb NIC. The bug was actually triggered, not just found by
code inspection.
Link: https://bugzilla.proxmox.com/show_bug.cgi?id=8318
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
---
Gabriel Goller (3):
net: restore the L3 header before VLAN TX offload checks
openvswitch: preserve the L3 header after stacked VLAN pushes
net: test stacked VLAN headers before TX offloads
net/core/dev.c | 17 +++
net/core/net_test.c | 145 +++++++++++++++++++++
net/openvswitch/actions.c | 6 +-
.../selftests/net/openvswitch/openvswitch.sh | 34 +++++
4 files changed, 201 insertions(+), 1 deletion(-)
---
base-commit: 8d5ce4751fad9499ea408163af7f410f18a85782
base-tree: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git main
change-id: 20261111-net_restore_the-59b5fb335fe3
Best regards,
--
Gabriel Goller <g.goller@proxmox.com>
next reply other threads:[~2026-11-11 17:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 17:37 Gabriel Goller [this message]
2026-11-11 17:37 ` [PATCH RFC net 1/3] net: restore the L3 header before VLAN TX offload checks Gabriel Goller
2026-11-11 17:37 ` [PATCH RFC net 2/3] openvswitch: preserve the L3 header after stacked VLAN pushes Gabriel Goller
2026-11-11 17:37 ` [PATCH RFC net 3/3] net: test stacked VLAN headers before TX offloads Gabriel Goller
2026-11-11 18:33 ` [PATCH RFC net 0/3] net: fix stacked VLAN header corruption in TX offloads and OVS Ilya Maximets
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=20261111-net_restore_the-v1-0-6aaeffa601c9@proxmox.com \
--to=g.goller@proxmox.com \
--cc=aconole@redhat.com \
--cc=boris.sukholitko@broadcom.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®