Re: [PATCH net] octeontx2-pf: fix skb use-after-free with ipsec crypto offload

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-10-21 at 12:29:27, Nicolai Buchwitz (nb@tipi-net.de) wrote:
> Hi Ratheesh
>
> On 21.10.2026 05:16, Ratheesh Kannoth wrote:
> > On 2026-10-19 at 20:34:33, Nicolai Buchwitz (nb@tipi-net.de) wrote:
> > >  	if (!seg) {
> > > diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> > > b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> > > index 8d2d607bc92f9..4a20d73d27c06 100644
> > > --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> > > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> > > @@ -1205,6 +1205,13 @@ bool otx2_sq_append_skb(void *dev, struct
> > > netdev_queue *txq,
> > >  	if (free_desc < otx2_get_sqe_count(pfvf, skb))
> > >  		return false;
> > >
> > > +	/* Crypto hardware need write permission for ipsec crypto offload */
> > > +	if (unlikely(xfrm_offload(skb)) && skb_cloned(skb) &&
> > > +	    skb_ensure_writable(skb, skb->len)) {
> >
> > Thanks for the fix!
> >
> > Just wanted to double-check the behavior of `skb_ensure_writable(skb,
> > skb->len)` on a cloned
> > SG packet. Does it end up copying the data twice (once via
> > `pskb_may_pull()` to linearize into
> > the shared buffer, and again via `pskb_expand_head()` into a new
> > buffer)?
> >
> > I'm a bit concerned about potential performance regressions.
>
> No, AFAIU it copies once. On a cloned skb it will be
>
>   __pskb_pull_tail()
>     -> pskb_expand_head()
>        -> private head, skb->cloned cleared
>
> The frags are copied into that head and skb_ensure_writable() returns.
> That matches what the old skb_unshare() did and also only cloned
> xfrm skbs take this path.

Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>

>
> > [...]
>
> Regards,
> Nicolai