patch 'eal: fix annotation on lcore variable allocator' has been queued to stable release 25.11.1

Kevin Traynor ktraynor at redhat.com
Thu Feb 26 14:08:49 CET 2026


Hi,

FYI, your patch has been queued to stable release 25.11.1

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 03/02/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/248d962d58094bcee5d0f5942121ba87f7d53432

Thanks.

Kevin

---
>From 248d962d58094bcee5d0f5942121ba87f7d53432 Mon Sep 17 00:00:00 2001
From: Scott Mitchell <scott.k.mitch1 at gmail.com>
Date: Sun, 1 Feb 2026 21:24:41 -0800
Subject: [PATCH] eal: fix annotation on lcore variable allocator
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[ upstream commit de5991dcd751f7bbe9596b750538803a7e187548 ]

The __rte_alloc_size(1) attribute on rte_lcore_var_alloc() is
semantically incorrect and causes false positives with FORTIFY_SOURCE
runtime checks.

The attribute tells the compiler that the function returns a pointer
to 'size' bytes of usable memory. However, rte_lcore_var_alloc()
actually returns a handle to a per-lcore variable scheme. The
allocator internally allocates 'size' bytes per lcore
(size * RTE_MAX_LCORE total), partitioned into per-lcore sections.
The handle points to lcore 0's copy, and accessed via
RTE_LCORE_VAR_LCORE(lcore_id, handle) which computes:
handle + (lcore_id * RTE_MAX_LCORE_VAR). Access is expected
beyond 'size' bytes beyond the returned pointer when 'lcore_id != 0'
but FORTIFY_SOURCE may terminate the program due to out of bounds
access.

This can be observed on CI with gcc 13.3.0 in lcore_var_autotest with
'*** buffer overflow detected ***: terminated' if pointer provenance
is preserved (e.g. if offsets avoid casting to uintptr_t).

Fixes: 5bce9bed67ad ("eal: add static per-lcore memory allocation facility")

Signed-off-by: Scott Mitchell <scott.k.mitch1 at gmail.com>
Acked-by: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
Acked-by: Stephen Hemminger <stephen at networkplumber.org>
Acked-by: Morten Brørup <mb at smartsharesystems.com>
---
 .mailmap                        | 1 +
 lib/eal/include/rte_lcore_var.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/.mailmap b/.mailmap
index d838ffb4db..98d9058267 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1438,4 +1438,5 @@ Savinay Dharmappa <savinay.dharmappa at intel.com>
 Scott Branden <scott.branden at broadcom.com>
 Scott Daniels <daniels at research.att.com>
+Scott Mitchell <scott.k.mitch1 at gmail.com> <scott_mitchell at apple.com>
 Scott W Taylor <scott.w.taylor at intel.com>
 Scott Wasson <scott_wasson at affirmednetworks.com>
diff --git a/lib/eal/include/rte_lcore_var.h b/lib/eal/include/rte_lcore_var.h
index ca31dff6fd..48b022e84e 100644
--- a/lib/eal/include/rte_lcore_var.h
+++ b/lib/eal/include/rte_lcore_var.h
@@ -203,5 +203,5 @@ __rte_experimental
 void *
 rte_lcore_var_alloc(size_t size, size_t align)
-	__rte_alloc_size(1) __rte_alloc_align(2);
+	__rte_alloc_align(2);
 
 #ifdef __cplusplus
-- 
2.53.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2026-02-26 10:16:48.963858524 +0000
+++ 0047-eal-fix-annotation-on-lcore-variable-allocator.patch	2026-02-26 10:16:46.963459290 +0000
@@ -1 +1 @@
-From de5991dcd751f7bbe9596b750538803a7e187548 Mon Sep 17 00:00:00 2001
+From 248d962d58094bcee5d0f5942121ba87f7d53432 Mon Sep 17 00:00:00 2001
@@ -8,0 +9,2 @@
+[ upstream commit de5991dcd751f7bbe9596b750538803a7e187548 ]
+
@@ -30 +31,0 @@
-Cc: stable at dpdk.org
@@ -42 +43 @@
-index 0e1e4b16b0..67183b09e5 100644
+index d838ffb4db..98d9058267 100644



More information about the stable mailing list