patch 'net/af_xdp: fix resource leak in close' has been queued to stable release 25.11.3

Kevin Traynor ktraynor at redhat.com
Thu Jul 23 19:14:35 CEST 2026


Hi,

FYI, your patch has been queued to stable release 25.11.3

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 07/27/26. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/81459d981a51f633cef75e0c9dd9361270e8da5e

Thanks.

Kevin

---
>From 81459d981a51f633cef75e0c9dd9361270e8da5e Mon Sep 17 00:00:00 2001
From: Ouyang Hao <ouyanghao at tencent.com>
Date: Tue, 7 Apr 2026 10:14:28 +0800
Subject: [PATCH] net/af_xdp: fix resource leak in close

[ upstream commit a164a0bd78c1f45779a63e8a8c84e296c4f08458 ]

The rx_queues and tx_queues arrays are allocated as contiguous
blocks via rte_zmalloc_socket() in init_internals(). However,
eth_dev_close() incorrectly calls rte_free() on individual array
elements (rxq and rxq->pair) inside the per-queue cleanup loop.

Since rte_free(&rx_queues[0]) releases the entire contiguous
block, the memory backing queues[1..N-1] becomes invalid after
the first iteration. On subsequent iterations, accessing the
freed memory may read NULL (or garbage), causing the loop to
break early via the (rxq->umem == NULL) check.

This results in:
- XSK sockets for queues 1..N-1 not being deleted
- UMEM reference counts not being decremented, leaking memory
- Potential use-after-free if freed memory is reallocated

Fix by removing the per-element rte_free() calls from inside
the loop and instead freeing the entire tx_queues and rx_queues
arrays after the loop completes.

Fixes: 339b88c6a91f ("net/af_xdp: support multi-queue")

Signed-off-by: Ouyang Hao <ouyanghao at tencent.com>
---
 .mailmap                            | 1 +
 drivers/net/af_xdp/rte_eth_af_xdp.c | 8 +++-----
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/.mailmap b/.mailmap
index 09901eec04..15c0960245 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1210,4 +1210,5 @@ Ophir Munk <ophirmu at nvidia.com> <ophirmu at mellanox.com>
 Or Ami <ora at mellanox.com>
 Ori Kam <orika at nvidia.com> <orika at mellanox.com>
+Ouyang Hao <ouyanghao at tencent.com>
 Owen Hilyard <ohilyard at iol.unh.edu>
 Pabitra Dalai <pabitra.dalai at intel.com>
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 10dbcf1333..2cdb533276 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -1070,10 +1070,8 @@ eth_dev_close(struct rte_eth_dev *dev)
 				rte_memory_order_acquire) - 1 == 0)
 			xdp_umem_destroy(rxq->umem);
-
-		/* free pkt_tx_queue */
-		rte_free(rxq->pair);
-		rte_free(rxq);
 	}
-
+	/* Free Tx and Rx queue arrays */
+	rte_free(internals->tx_queues);
+	rte_free(internals->rx_queues);
 	/*
 	 * MAC is not allocated dynamically, setting it to NULL would prevent
-- 
2.55.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2026-07-23 17:57:59.055947902 +0100
+++ 0012-net-af_xdp-fix-resource-leak-in-close.patch	2026-07-23 17:57:58.630918642 +0100
@@ -1 +1 @@
-From a164a0bd78c1f45779a63e8a8c84e296c4f08458 Mon Sep 17 00:00:00 2001
+From 81459d981a51f633cef75e0c9dd9361270e8da5e Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit a164a0bd78c1f45779a63e8a8c84e296c4f08458 ]
+
@@ -27 +28,0 @@
-Cc: stable at dpdk.org
@@ -36 +37 @@
-index 4d26d9c286..4d4b575597 100644
+index 09901eec04..15c0960245 100644
@@ -39 +40 @@
-@@ -1214,4 +1214,5 @@ Ophir Munk <ophirmu at nvidia.com> <ophirmu at mellanox.com>
+@@ -1210,4 +1210,5 @@ Ophir Munk <ophirmu at nvidia.com> <ophirmu at mellanox.com>



More information about the stable mailing list