On Fri, 23 Oct 2026 07:59:15 -0400 Jamal Hadi Salim wrote: > This series fixes a class of producer/consumer bugs in which an outer > header is popped and the packet is then handed to a consumer with fewer > than ETH_HLEN bytes in the linear area. eth_type_trans() pulls ETH_HLEN > from that area and can BUG in __skb_pull() when the inner Ethernet header > is not linear. The affected producers are act_vlan POP_ETH, act_mpls POP, > act_ife egress decode, and the Open vSwitch MPLS/TEB and NSH pops. A > consumer-side guard in act_mirred rejects redirecting a headerless packet > to a device that expects a link-layer header. > > Patch 1 makes act_vlan POP_ETH pull the inner Ethernet header after the > pop and drop only when the packet is genuinely shorter than ETH_HLEN. > Patch 2 does the same for act_mpls, gated on the pre-pop MAC length. > Patch 3 adds the act_mirred guard at the redirect boundary. Patch 4 > keeps act_ife egress decode from consuming the inner Ethernet header and > restores the header metadata. > > Patches 5 and 6 establish the same linear-header invariant for the OVS > MPLS/TEB and NSH pops before restoring MAC_PROTO_ETHERNET.
NIPA CI flagged a regression that appears to be introduced by this patch (or one of the closely related act_vlan/act_mirred patches in the same series). The selftest tools/testing/selftests/net/forwarding/tc_mpls_l2vpn.sh now fails reliably (both the "ping" and "ping6" sub-tests, on both the regular and debug forwarding test configs, consistently on retry as well): # TEST: ping [FAIL] # TEST: ping6 [FAIL] The test builds an Ethernet-over-MPLS L2VPN using exactly the tc action sequence this series touches: - ingress: mpls mac_push + vlan push_eth + mirred egress redirect - ingress: vlan pop_eth + mpls pop protocol teb + mirred egress redirect dmesg on the test run shows mirred failing to redirect the traffic: tc mirred to Houston: device veth2 is down tc mirred to Houston: device veth3 is down This is the same "vlan pop_eth followed by mpls pop" chain described in this patch's own commit message as the bug reproduction scenario, so it looks like the mac_len/pskb_may_pull bookkeeping added here may not be correctly handling the ingress case used by this test, causing otherwise valid packets built by this chain to be mishandled and the redirect to fail. Could you take a look at whether the new POP header-pull logic correctly handles the "vlan pop_eth -> mpls pop protocol teb -> mirred redirect" chain on ingress? It would also be worth double-checking this alongside the companion act_vlan POP_ETH and act_mirred link-layer-header patches from the same series, since they touch the same pipeline. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
