Re: [PATCH net v2 0/6] net: pull short linear Ethernet headers before eth_type_trans()

[Jakub Kicinski <kuba@kernel.org>]

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.