Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags

[Steffen Klassert <steffen.klassert@secunet.com>]

On Mon, May 04, 2026 at 12:56:50AM -0700, Eric Dumazet wrote:
> On Mon, May 4, 2026 at 12:53 AM Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > We have antoher patch that addresses this issue in a different way,
> > so Cc the author of the other patch.
> >
> > On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote:
> > > From: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > >
> > > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> > > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> > > so later paths that may modify packet data can first make a private
> > > copy. The IPv4/IPv6 datagram append paths did not set this flag when
> > > splicing pages into UDP skbs.
> > >
> > > That leaves an ESP-in-UDP packet made from shared pipe pages looking
> > > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> > > fast path for uncloned skbs without a frag_list and decrypts in place
> > > over data that is not owned privately by the skb.
> > >
> > > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> > > TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> > > present, so ESP does not decrypt externally backed frags in place.
> > > Private nonlinear skb frags still use the existing fast path.
> > >
> > > This intentionally does not change ESP output. In esp_output_head(),
> > > the path that appends the ESP trailer to existing skb tailroom without
> > > calling skb_cow_data() is not reachable for nonlinear skbs:
> > > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> > > tailen is positive. Thus ESP output will either use the separate
> > > destination-frag path or fall back to skb_cow_data().
> > >
> > > Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > > ---
> > >  net/ipv4/esp4.c       | 3 ++-
> > >  net/ipv4/ip_output.c  | 2 ++
> > >  net/ipv6/esp6.c       | 3 ++-
> > >  net/ipv6/ip6_output.c | 2 ++
> > >  4 files changed, 8 insertions(+), 2 deletions(-)
> >
> > This looks ok to me. From the IPsec point of view, I'm
> > fine with this patch, but it also touches generic
> > networking code. So I'd like to hear an opinion of one
> > of the networking maintainers before proceeding.
> 
> I have not seen a Fixes: tag.

Right, we need a v2 with a Fixes tag, and maybe also
'Cc: stable@vger.kernel.org'

> Do we need to split this patch into two parts?

I don't think we need to spilt it, we can merge it
either to the net or the ipsec tree. Both should
be OK.