From: sandeep.penigalapati@intel.com
To: dev@dpdk.org
Cc: Ciara Loftus <ciara.loftus@intel.com>,
Maryam Tahhan <mtahhan@redhat.com>,
Stephen Hemminger <stephen@networkplumber.org>,
stable@dpdk.org,
Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Subject: [PATCH v3] net/af_xdp: fix shared UMEM refcount corruption
Date: Mon, 17 Aug 2026 12:13:01 -0400 [thread overview]
Message-ID: <20260817161301.54049-1-sandeep.penigalapati@intel.com> (raw)
In-Reply-To: <20260814215107.114582-1-sandeep.penigalapati@intel.com>
From: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Shared UMEM is meant to be shared by a limited number of sockets,
governed by the mempool size (max_xsks). When the UMEM was already at
capacity (refcnt >= max_xsks), xdp_umem_configure() returned the UMEM
without incrementing its refcount, so the extra socket used it
unaccounted for.
This missing reference has two consequences. During queue setup the
fill-queue reservation is chosen from the refcount, so the sharing
socket reserves into its own uninitialised fill queue and crashes. At
close, the under-counted refcount reaches zero while the UMEM is still
in use, freeing it early and causing a use-after-free.
Reject sharing once the UMEM is at capacity by returning NULL, so queue
setup fails cleanly with -ENOMEM. This applies the per-mempool socket
limit that shared UMEM was always intended to respect.
Harden the failure path this makes reachable: clear rxq->umem and its
paired txq->umem when xsk_configure() fails, and skip queues whose UMEM
is not yet set in get_shared_umem(), so a later scan over the same
mempool cannot dereference a NULL or dangling UMEM.
Also document the shared mempool sizing requirement (4096 mbufs per
socket).
Note: on stable branches this is a behaviour change. Shared-UMEM setups
that previously appeared to start, until the fill-queue crash or the
use-after-free at close, now fail cleanly at Rx queue setup with
-ENOMEM.
Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM")
Cc: stable@dpdk.org
Signed-off-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
---
v3:
- Move the NULL umem check after ctx_exists() so a failed queue is still
checked for a duplicate context, as before.
- Shorten the "at capacity" log to one line and drop the count (always
the max here).
- Also clear txq->umem, not just rxq->umem, when setup fails.
- Clarify "AF_XDP socket" in the doc.
doc/guides/nics/af_xdp.rst | 7 +++++++
drivers/net/af_xdp/rte_eth_af_xdp.c | 19 ++++++++++++++++---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index c455b4c066..cf4eeb63d0 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -99,6 +99,13 @@ configured like so:
--vdev net_af_xdp0,iface=ens786f1,shared_umem=1 \
--vdev net_af_xdp1,iface=ens786f2,shared_umem=1
+The shared mempool must be large enough for every AF_XDP socket sharing
+the UMEM.
+Each socket requires 4096 mbufs, so a UMEM shared by ``N`` sockets needs at
+least ``4096 * N`` mbufs.
+Rx queue setup fails if the mempool is too small to add another socket to the
+UMEM.
+
xdp_prog
~~~~~~~~
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 2cdb533276..3838d52d5d 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -1154,6 +1154,9 @@ get_shared_umem(struct pkt_rx_queue *rxq, const char *ifname,
ret = -1;
goto out;
}
+ /* A failed setup leaves mb_pool set with no umem. */
+ if (internals->rx_queues[i].umem == NULL)
+ continue;
if (rte_atomic_load_explicit(&internals->rx_queues[i].umem->refcnt,
rte_memory_order_acquire)) {
*umem = internals->rx_queues[i].umem;
@@ -1188,9 +1191,16 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals *internals,
if (get_shared_umem(rxq, internals->if_name, &umem) < 0)
return NULL;
- if (umem != NULL &&
- rte_atomic_load_explicit(&umem->refcnt, rte_memory_order_acquire) <
- umem->max_xsks) {
+ if (umem != NULL) {
+ /* Reject sharing once the UMEM is at capacity. */
+ if (rte_atomic_load_explicit(&umem->refcnt,
+ rte_memory_order_acquire) >= umem->max_xsks) {
+ AF_XDP_LOG_LINE(ERR, "%s,qid%i: UMEM %s already at max %u sockets",
+ internals->if_name, rxq->xsk_queue_idx,
+ umem->mb_pool->name, umem->max_xsks);
+ return NULL;
+ }
+
AF_XDP_LOG_LINE(INFO, "%s,qid%i sharing UMEM",
internals->if_name, rxq->xsk_queue_idx);
rte_atomic_fetch_add_explicit(&umem->refcnt, 1, rte_memory_order_acquire);
@@ -1818,6 +1828,9 @@ xsk_configure(struct pmd_internals *internals, struct pkt_rx_queue *rxq,
out_umem:
if (rte_atomic_fetch_sub_explicit(&rxq->umem->refcnt, 1, rte_memory_order_acquire) - 1 == 0)
xdp_umem_destroy(rxq->umem);
+ /* Drop dangling pointers so a later shared-UMEM scan skips this queue. */
+ rxq->umem = NULL;
+ txq->umem = NULL;
return ret;
}
--
2.27.0
next prev parent reply other threads:[~2026-08-17 9:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 22:08 [PATCH v1] net/af_xdp: fix shared UMEM refcount corruption sandeep.penigalapati
2026-08-12 20:56 ` Stephen Hemminger
2026-08-14 21:51 ` [PATCH v2] " sandeep.penigalapati
2026-08-14 15:46 ` Stephen Hemminger
2026-08-17 16:13 ` sandeep.penigalapati [this message]
2026-08-18 14:07 ` [PATCH v3] " Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260817161301.54049-1-sandeep.penigalapati@intel.com \
--to=sandeep.penigalapati@intel.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=mtahhan@redhat.com \
--cc=stable@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox