mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sewook Seo <sewookseo@google.com>
To: Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	 "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>
Cc: "Simon Horman" <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@android.com, "Sewook Seo" <sewookseo@google.com>,
	stable@vger.kernel.org, "Maciej Żenczykowski" <maze@google.com>,
	"Lorenzo Colitti" <lorenzo@google.com>
Subject: [PATCH ipsec] xfrm: check inner family via skb_dst for small_ipv6 DF clearing
Date: Tue, 10 Nov 2026 09:25:12 +0000	[thread overview]
Message-ID: <20261110092513.2375648-1-sewookseo@google.com> (raw)

Commit 6821ad877034 ("xfrm: do not set IPv4 DF flag when encapsulating
IPv6 frames <= 1280 bytes.") intended to clear the outer IPv4 DF bit in
xfrm4_tunnel_encap_add() when encapsulating inner IPv6 frames of at most
IPV6_MIN_MTU (1280) bytes, by checking skb->protocol == htons(ETH_P_IPV6).

However, its caller xfrm4_prepare_output() overwrites skb->protocol with
htons(ETH_P_IP) before invoking xfrm4_tunnel_encap_add(), since
commit 0c620e97b349 ("xfrm: remove output indirection from xfrm_mode").
As a result, small_ipv6 always evaluates to false, leaving IP_DF set on
outer IPv4 tunnel packets even when encapsulating <= 1280-byte IPv6
frames.

This issue was observed on devices in production use over IPv6-in-IPv4
ESP-in-UDP tunnels where an intermediate IPv4 link has an MTU smaller
than the encapsulated packet size (e.g. < 1362 bytes) and ICMPv4
Fragmentation Needed errors are either filtered or not actionable below
IPV6_MIN_MTU, causing encapsulated <= 1280-byte IPv6 packets to be
dropped instead of fragmented by the outer IPv4 router.

At the time xfrm4_tunnel_encap_add() runs, skb_dst(skb) has not been
popped yet and still represents the inner packet destination entry, as
already used a few lines below to set top_iph->protocol via
xfrm_af2proto(skb_dst(skb)->ops->family), while skb->len still holds the
unencapsulated inner packet length. Check dst->ops->family == AF_INET6
instead of skb->protocol so small_ipv6 works as intended.

Tested on User-Mode Linux (ARCH=um) with a four-namespace IPv6-over-IPv4
XFRM ESP tunnel reproducer across a 1300-byte MTU router link with ICMPv4
Fragmentation Needed filtered (verifying 1280-byte inner IPv6 frames fail
before the fix and pass via outer IPv4 fragmentation with the fix, while
larger frames still preserve outer IP_DF), and verified all tests pass in
tools/testing/selftests/net/xfrm_state.sh.

Fixes: 6821ad877034 ("xfrm: do not set IPv4 DF flag when encapsulating IPv6 frames <= 1280 bytes.")
Cc: stable@vger.kernel.org
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Assisted-by: LLM
Signed-off-by: Sewook Seo <sewookseo@google.com>
---
 net/xfrm/xfrm_output.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index f1f612cd7b43..60ffe9549c09 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -275,11 +275,14 @@ static int xfrm4_beet_encap_add(struct xfrm_state *x, struct sk_buff *skb)
  */
 static int xfrm4_tunnel_encap_add(struct xfrm_state *x, struct sk_buff *skb)
 {
-	bool small_ipv6 = (skb->protocol == htons(ETH_P_IPV6)) && (skb->len <= IPV6_MIN_MTU);
 	struct dst_entry *dst = skb_dst(skb);
 	struct iphdr *top_iph;
+	bool small_ipv6;
 	int flags;
 
+	small_ipv6 = (dst->ops->family == AF_INET6) &&
+		     (skb->len <= IPV6_MIN_MTU);
+
 	if (!skb->inner_protocol) {
 		skb_set_inner_network_header(skb, skb_network_offset(skb));
 		skb_set_inner_transport_header(skb, skb_transport_offset(skb));
-- 
2.56.0.542.g3ef89b7020-goog


                 reply	other threads:[~2026-11-10  9:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261110092513.2375648-1-sewookseo@google.com \
    --to=sewookseo@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=kernel-team@android.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=steffen.klassert@secunet.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 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®