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

[Hyunwoo Kim <imv4bel@gmail.com>]

On Mon, May 04, 2026 at 10:06:18AM +0200, Steffen Klassert wrote:
> 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.

Also, please add:
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>


Best regards,
Hyunwoo Kim