All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Eric Dumazet <edumazet@kernel.org>,
	 "David S . Miller" <davem@davemloft.net>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemb@google.com>,
	 Simon Horman <horms@kernel.org>,
	 netdev@vger.kernel.org,  Eric Dumazet <edumazet@kernel.org>,
	 Andrew Lunn <andrew+netdev@lunn.ch>,
	 Aaron Conole <aconole@redhat.com>,
	 Eelco Chaudron <echaudro@redhat.com>,
	 Ilya Maximets <i.maximets@ovn.org>,
	 Jamal Hadi Salim <jhs@mojatatu.com>,
	 Jiri Pirko <jiri@resnulli.us>,
	 dev@openvswitch.org,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Ren Wei <weir@nebusec.ai>
Subject: Re: [PATCH net 0/5] net: fix eth_type_trans() crashes on skbs coming from the stack
Date: Tue, 27 Oct 2026 10:40:48 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.22807e0fe104d@gmail.com> (raw)
In-Reply-To: <20261027082604.1485903-1-edumazet@kernel.org>

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:

Definitely a nice approach.

You previously suggested catching most of the TC modifications with a
single check in sch_handle_(e|in)gress. Is that no longer needed?

The few mirred/redirect cases are a bane, causing so many issues. And
escape any such check, as they call netif_receive_skb, netif_rx,
dev_queue_xmit, directly.

If it's only act_mirred, bpf_redirect and OVS, maybe a single
validation helper across all three before they pass to the rx/tx
path, that for starters calls eth_type_trans_careful. It quite likely
won't be the last packet corruption they are capable of..

> 
> - Patch 1 adds eth_type_trans_careful(), which pulls the Ethernet
>   header first and returns a drop reason on failure.
> - Patch 2 uses it in loopback_xmit().
> - Patch 3 uses it in __dev_forward_skb2(), used by BPF redirects to
>   ingress and by veth, macvlan, ipvlan, netdevsim and l2tp_eth.
> - Patch 4 uses it in OVS internal_dev_recv(), covering both the MPLS
>   (TEB) and NSH pop cases at once (only the MPLS case was tested).
> - Patch 5 (from Jamal) fixes act_ife decode on egress, which was
>   consuming the inner Ethernet header. This is no longer a crash after
>   patch 2, but egress decode never delivered a correct frame.
> 
> Other eth_type_trans() users already pull the header or never see
> such skbs:
> - vrf_process_v{4,6}_outbound() already pull ETH_HLEN + IP header
>   before vrf_local_xmit().
> - tun already uses pskb_may_pull_reason(skb, ETH_HLEN).
> - XDP: bpf_xdp_adjust_head() and bpf_xdp_adjust_tail() keep at least
>   ETH_HLEN bytes in the linear part, and multi-buffer tail shrinking
>   only trims frags.
> 
> Tested under virtme-ng with AF_PACKET reproducers. Without the series,
> all four cases crash in eth_type_trans():
> - lo egress "action vlan pop_eth", eth/eth/8192 bytes frame
> - lo egress "action ife decode pipe", IFE frame with 8192 bytes payload
> - lo egress "action vlan pop_eth continue", then a BPF program doing
>   bpf_skb_change_head(skb, 1, 0) + bpf_redirect(veth1, BPF_F_INGRESS)
> - OVS flow "pop_eth,pop_mpls(0x6558),0" to the internal port,
>   eth/mpls/eth/4096 bytes frame
> With the series, no crash. An ICMP echo inside an IFE frame decoded
> on lo egress is now received and answered. Normal traffic on lo,
> veth (including 8000 byte pings) and vrf is unchanged.
> 
> Link: https://lore.kernel.org/netdev/20261005052249.1914367-2-weir@nebusec.ai/
> Link: https://lore.kernel.org/netdev/ACT-N6N4.v3.r0.20261023200137-4@mojatatu.com/
> 
> Eric Dumazet (4):
>   net: add eth_type_trans_careful()
>   loopback: use eth_type_trans_careful()
>   net: use eth_type_trans_careful() in __dev_forward_skb2()
>   openvswitch: use eth_type_trans_careful() in internal_dev_recv()
> 
> Jamal Hadi Salim (1):
>   net/sched: act_ife: do not consume the inner header on egress
> 
>  drivers/net/loopback.c               |  8 +++++++-
>  include/linux/etherdevice.h          | 28 ++++++++++++++++++++++++++++
>  net/core/dev.c                       | 18 +++++++++++++-----
>  net/openvswitch/vport-internal_dev.c |  8 +++++++-
>  net/sched/act_ife.c                  |  4 ++++
>  5 files changed, 59 insertions(+), 7 deletions(-)
> 
> -- 
> 2.53.0
> 



  parent reply	other threads:[~2026-10-27 14:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27  8:25 [PATCH net 0/5] net: fix eth_type_trans() crashes on skbs coming from the stack Eric Dumazet
2026-10-27  8:26 ` [PATCH net 1/5] net: add eth_type_trans_careful() Eric Dumazet
2026-10-27 13:51   ` Aaron Conole
2026-10-27 15:02   ` Willem de Bruijn
2026-10-27  8:26 ` [PATCH net 2/5] loopback: use eth_type_trans_careful() Eric Dumazet
2026-10-27  8:26 ` [PATCH net 3/5] net: use eth_type_trans_careful() in __dev_forward_skb2() Eric Dumazet
2026-10-27  8:26 ` [PATCH net 4/5] openvswitch: use eth_type_trans_careful() in internal_dev_recv() Eric Dumazet
2026-10-27 13:50   ` Aaron Conole
2026-10-27  8:26 ` [PATCH net 5/5] net/sched: act_ife: do not consume the inner header on egress Eric Dumazet
2026-10-27  9:17 ` [PATCH net 0/5] net: fix eth_type_trans() crashes on skbs coming from the stack Jamal Hadi Salim
2026-10-27  9:51   ` Eric Dumazet
2026-10-27 13:07     ` Jamal Hadi Salim
2026-10-27 14:00       ` Aaron Conole
2026-10-27 14:33       ` Eric Dumazet
2026-10-27 14:40 ` Willem de Bruijn [this message]
2026-10-27 15:49   ` Eric Dumazet
2026-10-27 19:48     ` Jamal Hadi Salim
2026-10-27 20:34       ` Eric Dumazet
2026-10-27 21:20         ` Jamal Hadi Salim
2026-10-27 21:25 ` Jakub Kicinski
2026-10-28  5:02   ` Eric Dumazet

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=willemdebruijn.kernel.22807e0fe104d@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=aconole@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --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=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=weir@nebusec.ai \
    --cc=willemb@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.