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

[Nicolai Buchwitz <nb@tipi-net.de>]

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.

> [...]

Regards,
Nicolai