Re: [PATCH net 0/5] net: fix eth_type_trans() crashes on skbs coming from the stack

On Tue, 27 Oct 2026 09:25:59 +0100 Eric Dumazet wrote:

eth_type_trans() assumes ETH_HLEN bytes are present in skb->head.
NIC drivers always provide this, and they should keep using the fast
version, without an extra pskb_may_pull().

Devices looping skbs from their transmit path back to their receive
path get skbs built by the stack instead. tc actions (act_vlan pop_eth,
act_ife decode), BPF helpers (bpf_skb_change_head() before a redirect)
or OVS actions (pop_eth followed by pop_mpls/pop_nsh) can leave fewer
than ETH_HLEN bytes in the linear part, and eth_type_trans() then hits
the BUG() in __skb_pull().

Instead of fixing every producer, or adding a check to all
eth_type_trans() users, fix the few consumers exposed to this:

Bot says:

BPF CI (bpf-ci) is reporting a consistent regression with this patch
applied: every single job variant (x86-64/aarch64/s390x, gcc/llvm,
no-alu32/cpuv4/ASAN) fails the exact same selftest subtest:

  #135 empty_skb

Specifically, the "veth ETH_HLEN+1 packet ingress [redirect_ingress]"
case in tools/testing/selftests/bpf/prog_tests/empty_skb.c now fails:

  test_empty_skb:FAIL:ret: veth ETH_HLEN+1 packet ingress [redirect_ingress]
  unexpected ret: actual 1 != expected 0

That test redirects a minimal (ETH_HLEN+1-byte) skb to a veth's RX path
via bpf_clone_redirect(..., BPF_F_INGRESS), which goes through
dev_forward_skb() -> __dev_forward_skb2(). Before this change the skb
was forwarded successfully (ret == 0); after switching to
eth_type_trans_careful() it is now dropped (actual == 1, i.e.
NET_RX_DROP).

Could you take a look at whether the new drop-on-failure behavior in
__dev_forward_skb2() is intentional for this previously-accepted
ETH_HLEN+1 packet, and if so, update the empty_skb selftest's expected
return value alongside this change? Right now the selftest and the new
kernel behavior disagree, and it's failing 100% of the time in CI on
every arch/toolchain/config combination we run.