From: Todd Freed <toddfreed@meta.com>
To: <netfilter-devel@vger.kernel.org>, <toddfreed@meta.com>
Cc: "Pablo Neira Ayuso" <pablo@netfilter.org>,
"Florian Westphal" <fw@strlen.de>, "Phil Sutter" <phil@nwl.cc>,
"Nikolay Aleksandrov" <razor@blackwall.org>,
"Ido Schimmel" <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Boris Pismenny" <borisp@nvidia.com>,
"Sabrina Dubroca" <sd@queasysnail.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Daniel Zahka" <daniel.zahka@gmail.com>,
"Willem de Bruijn" <willemdebruijn.kernel@gmail.com>,
"Björn Töpel" <bjorn@kernel.org>,
coreteam@netfilter.org, bridge@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH nf-next v1 1/2] netfilter: bridge: don't refragment decrypted skbs
Date: Tue, 10 Nov 2026 16:31:10 -0800 [thread overview]
Message-ID: <20261111003111.3826942-2-toddfreed@meta.com> (raw)
In-Reply-To: <20261111003111.3826942-1-toddfreed@meta.com>
on transmit, skb->decrypted means that the device must encrypt the skb
or drop it. this applies to psp offload and ktls offload. those
offloads cannot support fragments. they need the packet's l4 header, and
non-initial fragments do not have it. therefore, the ip stack doesn't
fragment decrypted skbs.
"net: don't fragment decrypted skbs" (net) drops decrypted skbs in
ip_do_fragment() and ip6_fragment(), instead of fragmenting them.
nf_conntrack_bridge refragments the packets it reassembled with its own
functions, which don't have that check: nf_br_ip_fragment() for ipv4,
and br_ip6_fragment() for ipv6. br_netfilter uses ip_do_fragment() and
ip6_fragment(), and is covered by the net patch.
a packet which a psp device decrypted, and which is bridged without
being re-encrypted, gets there if the peer sends ip fragments inside
psp: bridge conntrack reassembles them into one decrypted skb. its
fragments couldn't be encrypted, and the ones built from scratch don't
carry the decrypted mark, so they'd leave the bridge port in clear text.
drop decrypted skbs in nf_br_ip_fragment() and br_ip6_fragment(), as
the ip stack does.
Signed-off-by: Todd Freed <toddfreed@meta.com>
---
net/bridge/netfilter/nf_conntrack_bridge.c | 6 ++++++
net/ipv6/netfilter.c | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/net/bridge/netfilter/nf_conntrack_bridge.c b/net/bridge/netfilter/nf_conntrack_bridge.c
index b5444335b86f..0069734853fd 100644
--- a/net/bridge/netfilter/nf_conntrack_bridge.c
+++ b/net/bridge/netfilter/nf_conntrack_bridge.c
@@ -38,6 +38,12 @@ static int nf_br_ip_fragment(struct net *net, struct sock *sk,
struct iphdr *iph;
int err = 0;
+ /* PSP and TLS offload need the packet's L4 header, which non-initial
+ * fragments do not have.
+ */
+ if (unlikely(skb_is_decrypted(skb)))
+ goto blackhole;
+
/* for offloaded checksums cleanup checksum before fragmentation */
if (skb->ip_summed == CHECKSUM_PARTIAL) {
err = ip_check_csum_start(skb);
diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
index a7025ec87035..e538f1c8d602 100644
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -124,6 +124,12 @@ int br_ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
int hroom, err = 0;
__be32 frag_id;
+ /* PSP and TLS offload need the packet's L4 header, which non-initial
+ * fragments do not have.
+ */
+ if (unlikely(skb_is_decrypted(skb)))
+ goto blackhole;
+
err = ip6_find_1stfragopt(skb, &prevhdr);
if (err < 0)
goto blackhole;
--
2.53.0-Meta
next prev parent reply other threads:[~2026-11-11 0:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 0:31 [PATCH nf-next 0/2] netfilter: don't send decrypted skbs in clear text Todd Freed
2026-11-11 0:31 ` Todd Freed [this message]
2026-11-11 0:31 ` [PATCH nf-next v1 2/2] netfilter: reject: don't reply to decrypted skbs Todd Freed
2026-11-11 0:36 ` [PATCH nf-next 0/2] netfilter: don't send decrypted skbs in clear text netdev-bot+sinfo
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=20261111003111.3826942-2-toddfreed@meta.com \
--to=toddfreed@meta.com \
--cc=bjorn@kernel.org \
--cc=borisp@nvidia.com \
--cc=bridge@lists.linux.dev \
--cc=coreteam@netfilter.org \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=razor@blackwall.org \
--cc=sd@queasysnail.net \
--cc=willemdebruijn.kernel@gmail.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®