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

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

[Nicolai Buchwitz]

otx2_dma_map_skb_frag() calls skb_unshare() on its own copy of the skb
pointer. For a cloned skb, for example with tcpdump running on the
interface, this frees the skb and the new copy is lost on return. The
transmit path then uses the freed skb and the copy leaks.

Make the skb writable in place in otx2_sq_append_skb() instead, so the
pointer stays valid.

Fixes: 195c3d463181 ("octeontx2-pf: map skb data as device writeable")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
This was flagged in the clashiko review of my skb_unshare() rename patch [1].

Compile-tested only, I have no octeontx2 hardware.

[1] https://lore.kernel.org/all/20261015-nb-skb-unclone-full-v1-1-0dfbf01f60f2@tipi-net.de/
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 4 +---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c   | 7 +++++++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index b11389a841d15..91ebf247f5f90 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -2121,10 +2121,8 @@ dma_addr_t otx2_dma_map_skb_frag(struct otx2_nic *pfvf,
 	int offset;
 
 	/* Crypto hardware need write permission for ipsec crypto offload */
-	if (unlikely(xfrm_offload(skb))) {
+	if (unlikely(xfrm_offload(skb)))
 		dir = DMA_BIDIRECTIONAL;
-		skb = skb_unshare(skb, GFP_ATOMIC);
-	}
 
 	/* First segment is always skb->data */
 	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)) {
+		dev_kfree_skb_any(skb);
+		return true;
+	}
+
 	num_segs = skb_shinfo(skb)->nr_frags + 1;
 
 	/* If SKB doesn't fit in a single SQE, linearize it.

---
base-commit: 78731b46967e3e7102b5cd5062bef185f3404b5c
change-id: 20261019-nb-otx2-xfrm-unshare-net-6b74a96a8d9e

Best regards,
--  
Nicolai Buchwitz <nb@tipi-net.de>

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

[Ratheesh Kannoth]

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.

> +		dev_kfree_skb_any(skb);
> +		return true;
> +	}
> +
>  	num_segs = skb_shinfo(skb)->nr_frags + 1;
>
>  	/* If SKB doesn't fit in a single SQE, linearize it.
>
> ---
> base-commit: 78731b46967e3e7102b5cd5062bef185f3404b5c
> change-id: 20261019-nb-otx2-xfrm-unshare-net-6b74a96a8d9e
>
> Best regards,
> --
> Nicolai Buchwitz <nb@tipi-net.de>
>