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

[Eric Dumazet]

On Mon, May 4, 2026 at 12:53 AM Steffen Klassert
<steffen.klassert@xxxxxxxxxxx> 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@xxxxxxxxx>
> >
> > 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@xxxxxxxxx>
> > ---
> >  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.

Do we need to split this patch into two parts?