Re: [PATCH net v2 1/2] net: Make PSP skb extension survive packet scrubbing
From: Wei Wang
Date: Thu Nov 05 2026 - 19:27:24 EST
On Thu, Nov 5, 2026 at 6:09 AM Daniel Zahka <daniel.zahka@xxxxxxxxx> wrote:
>
> On Fri Oct 30, 2026 at 12:31 AM EDT, Wei Wang wrote:
> > skb_scrub_packet() drops all skb extensions unconditionally via
> > skb_ext_reset(). It runs on tunnel encap/decap (ip_tunnel_rcv, vxlan_rcv,
> > etc.) and virtual device forwarding/redirection (dev_forward_skb,
> > netkit_xmit, skb_do_redirect).
> >
> > When a virtual device such as netkit is associated with a PSP device in
> > another network namespace via PSP_CMD_DEV_ASSOC, incoming PSP packets
> > decapsulated by psp_dev_rcv() lose their SKB_EXT_PSP extension when
> > scrubbed during redirection into the peer netns. Without SKB_EXT_PSP,
> > __psp_sk_rx_policy_check() rejects incoming TCP data segments at the
> > socket layer with SKB_DROP_REASON_PSP_INPUT.
> >
> > Introduce a static skb_ext_scrub() helper in net/core/skbuff.c to
> > preserve SKB_EXT_PSP across skb_scrub_packet() while dropping all other
> > extensions. If SKB_EXT_PSP is not active, skb_ext_scrub() simply calls
> > skb_ext_reset(). If SKB_EXT_PSP is the only extension in the skb_ext
> > buffer, nothing needs to be scrubbed. Otherwise, save the PSP metadata,
> > reset the extension block, and re-add a fresh SKB_EXT_PSP extension (or
> > clear skb->decrypted if the allocation fails).
> >
> > Fixes: 06c2dce2d0f6 ("psp: add new netlink cmd for dev-assoc and dev-disassoc")
> > Link: https://lore.kernel.org/r/20260910-bpf-meta-inside-skb-ext-v2-3-0b21e42180b0@xxxxxxxxxxxxxx
> > Reported-by: Daniel Zahka <daniel.zahka@xxxxxxxxx>
> > Closes: https://lore.kernel.org/netdev/DLODSKPY6ON6.1G6SP3CFFLCPJ@xxxxxxxxx/
> > Co-developed-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx>
> > Signed-off-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx>
> > Signed-off-by: Wei Wang <weiwan@xxxxxxxxxx>
> > ---
> > net/core/skbuff.c | 31 +++++++++++++++++++++++++++++--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 93c2f440b9ec..5c4a2e982ebc 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -6369,6 +6369,32 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
> > }
> > EXPORT_SYMBOL(skb_try_coalesce);
> >
> > +static void skb_ext_scrub(struct sk_buff *skb)
> > +{
> > +#if IS_ENABLED(CONFIG_INET_PSP)
> > + struct psp_skb_ext *pse = skb_ext_find(skb, SKB_EXT_PSP);
> > +
> > + if (pse) {
> > + struct skb_ext *ext = skb->extensions;
> > + struct psp_skb_ext tmp = *pse;
>
> I would move the copy just before skb_ext_reset(skb), but it probably
> won't make a difference in the generated code.
>
> > +
> > + /* Nothing else to scrub if PSP is the only extension in ext. */
> > + if (ext->chunks == SKB_EXT_CHUNKSIZEOF(*ext) +
> > + skb_ext_type_len[SKB_EXT_PSP])
> > + return;
> > +
> > + skb_ext_reset(skb);
> > + pse = skb_ext_add(skb, SKB_EXT_PSP);
> > + if (pse)
> > + memcpy(pse, &tmp, sizeof(*pse));
> > + else
> > + skb->decrypted = 0;
>
> Agree with sashiko not to clear decrypted. It would at least prevent the
> skb from being forwarded cleartext back onto the network.
>
Yea, makes sense. Removing this in the next version.
> > + return;
> > + }
> > +#endif
> > + skb_ext_reset(skb);
> > +}
> > +
> > /**
> > * skb_scrub_packet - scrub an skb
> > *
> > @@ -6380,7 +6406,8 @@ EXPORT_SYMBOL(skb_try_coalesce);
> > * operations.
> > * skb_scrub_packet can also be used to clean a skb before injecting it in
> > * another namespace (@xnet == true). We have to clear all information in the
> > - * skb that could impact namespace isolation.
> > + * skb that could impact namespace isolation. Note that PSP skb extension is
> > + * preserved across packet scrubbing by design.
> > */
> > void skb_scrub_packet(struct sk_buff *skb, bool xnet)
> > {
> > @@ -6388,7 +6415,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
> > skb->skb_iif = 0;
> > skb->ignore_df = 0;
> > skb_dst_drop(skb);
> > - skb_ext_reset(skb);
> > + skb_ext_scrub(skb);
> > nf_reset_ct(skb);
> > nf_reset_trace(skb);
> >
>
> The only thing I would say is that skb_ext_scrub() won't scale if a
> second extension comes along and wants the same treatment as PSP. In
> that case, either we could make a bitmap of "no scrub" extensions and
> then use the same approach of allocating a new ext block and copying
> them over, or the original approach of skb_ext_del() could be used after
> changing the reference counting scheme for the special extensions in the
> release path of __skb_ext_put(), but that is a more intrusive change.
>
> I'm ok with the approach from a PSP perspective:
ACK.
>
> Reviewed-by: Daniel Zahka <daniel.zahka@xxxxxxxxx>