On Thu Sep 3, 2026 at 7:36 PM CEST, Adarsh Jagadish Kamini via lists.openembedded.org wrote: > On 9/3/26 19:03, Sadineni, Harish via lists.openembedded.org wrote: >> From: Harish Sadineni <[email protected]> >> >> Allocate the maximum array sizes directly, instead of resizing >> the arrays as needed. This eliminates alloca usage from the >> function, and fixes the out-of-bounds accesses. The asserts >> guard against the bug coming back if the balancing of the tree >> turns out not to work correctly. >> >> Upstream-Status: Backport >> [https://sourceware.org/git/?p=glibc.git;a=patch;h=e2789c46e3bfdcd67a82bea9946b315c179e83d3] >> CVE: CVE-2026-19542 >> >> Reference: >> [1]https://security-tracker.debian.org/tracker/CVE-2026-19542 >> [2]https://sourceware.org/bugzilla/show_bug.cgi?id=34506 >> [3]https://sourceware.org/git/?p=glibc.git;a=commit;h=e2789c46e3bfdcd67a82bea9946b315c179e83d3 >> >> Signed-off-by: Harish Sadineni <[email protected]> >> --- >> .../glibc/glibc/0023-CVE-2026-19542.patch | 98 +++++++++++++++++++ >> meta/recipes-core/glibc/glibc_2.43.bb | 1 + >> 2 files changed, 99 insertions(+) >> create mode 100644 meta/recipes-core/glibc/glibc/0023-CVE-2026-19542.patch >> >> diff --git a/meta/recipes-core/glibc/glibc/0023-CVE-2026-19542.patch >> b/meta/recipes-core/glibc/glibc/0023-CVE-2026-19542.patch >> new file mode 100644 >> index 0000000000..d4b42c6ea4 >> --- /dev/null >> +++ b/meta/recipes-core/glibc/glibc/0023-CVE-2026-19542.patch >> @@ -0,0 +1,98 @@ >> +From e2789c46e3bfdcd67a82bea9946b315c179e83d3 Mon Sep 17 00:00:00 2001 >> +From: Florian Weimer <[email protected]> >> +Date: Fri, 14 Aug 2026 13:41:16 +0200 >> +Subject: [PATCH] misc: Fix out-of-bounds array write in tdelete (bug 34506) >> + >> +Allocate the maximum array sizes directly, instead of resizing >> +the arrays as needed. This eliminates alloca usage from the >> +function, and fixes the out-of-bounds accesses. The asserts >> +guard against the bug coming back if the balancing of the tree >> +turns out not to work correctly. >> + >> +CVE: CVE-2025-19542 >> +Upstream-Status: Backport >> [https://sourceware.org/git/?p=glibc.git;a=patch;h=e2789c46e3bfdcd67a82bea9946b315c179e83d3] >> + >> +Reviewed-by: Adhemerval Zanella <[email protected]> >> +Signed-off-by: Harish Sadineni <[email protected]> >> +--- >> + misc/tsearch.c | 31 +++++++++++-------------------- >> + 1 file changed, 11 insertions(+), 20 deletions(-) >> + >> +diff --git a/misc/tsearch.c b/misc/tsearch.c >> +index 9b2eb34b25..e517dfa712 100644 >> +--- a/misc/tsearch.c >> ++++ b/misc/tsearch.c >> +@@ -85,6 +85,7 @@ >> + #include <assert.h> >> + #include <stdalign.h> >> + #include <stddef.h> >> ++#include <stdint.h> >> + #include <stdlib.h> >> + #include <string.h> >> + #include <search.h> >> +@@ -406,12 +407,13 @@ __tdelete (const void *key, void **vrootp, >> __compar_fn_t compar) >> + int cmp; >> + node *rootp = (node *) vrootp; >> + node root, unchained; >> +- /* Stack of nodes so we remember the parents without recursion. It's >> +- _very_ unlikely that there are paths longer than 40 nodes. The tree >> +- would need to have around 250.000 nodes. */ >> +- int stacksize = 40; >> ++ /* Stack of nodes so we remember the parents without recursion. The >> ++ stack size is a conservative approximation of the maximum height >> ++ of a red-black tree, based on size of the address space. >> ++ Actual numbers are closer to 57 (32 bit) and 117 (63 bit). */ >> ++ enum { stacksize = 2 * UINTPTR_WIDTH }; >> + int sp = 0; >> +- node **nodestack = alloca (sizeof (node *) * stacksize); >> ++ node *nodestack[stacksize]; >> + >> + if (rootp == NULL) >> + return NULL; >> +@@ -424,14 +426,7 @@ __tdelete (const void *key, void **vrootp, >> __compar_fn_t compar) >> + root = DEREFNODEPTR(rootp); >> + while ((cmp = (*compar) (key, root->key)) != 0) >> + { >> +- if (sp == stacksize) >> +- { >> +- node **newstack; >> +- stacksize += 20; >> +- newstack = alloca (sizeof (node *) * stacksize); >> +- nodestack = memcpy (newstack, nodestack, sp * sizeof (node *)); >> +- } >> +- >> ++ assert (sp < stacksize); >> + nodestack[sp++] = rootp; >> + p = DEREFNODEPTR(rootp); >> + if (cmp < 0) >> +@@ -470,13 +465,7 @@ __tdelete (const void *key, void **vrootp, >> __compar_fn_t compar) >> + node upn; >> + for (;;) >> + { >> +- if (sp == stacksize) >> +- { >> +- node **newstack; >> +- stacksize += 20; >> +- newstack = alloca (sizeof (node *) * stacksize); >> +- nodestack = memcpy (newstack, nodestack, sp * sizeof (node *)); >> +- } >> ++ assert (sp < stacksize); >> + nodestack[sp++] = parentp; >> + parentp = up; >> + upn = DEREFNODEPTR(up); >> +@@ -541,6 +530,7 @@ __tdelete (const void *key, void **vrootp, >> __compar_fn_t compar) >> + SETNODEPTR(pp,q); >> + /* Make sure pp is right if the case below tries to use >> + it. */ >> ++ assert (sp < stacksize); >> + nodestack[sp++] = pp = LEFTPTR(q); >> + q = RIGHT(p); >> + } >> +@@ -625,6 +615,7 @@ __tdelete (const void *key, void **vrootp, >> __compar_fn_t compar) >> + SETLEFT(p,RIGHT(q)); >> + SETRIGHT(q,p); >> + SETNODEPTR(pp,q); >> ++ assert (sp < stacksize); >> + nodestack[sp++] = pp = RIGHTPTR(q); >> + q = LEFT(p); >> + } >> diff --git a/meta/recipes-core/glibc/glibc_2.43.bb >> b/meta/recipes-core/glibc/glibc_2.43.bb >> index 9f3a3814d0..3ef2301191 100644 >> --- a/meta/recipes-core/glibc/glibc_2.43.bb >> +++ b/meta/recipes-core/glibc/glibc_2.43.bb >> @@ -55,6 +55,7 @@ SRC_URI = >> "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ >> >> file://0020-fix-create-thread-failed-in-unprivileged-process-BZ-.patch \ >> >> file://0021-tests-Skip-2-qemu-tests-that-can-hang-in-oe-selftest.patch \ >> >> file://0022-Propagate-ffile-prefix-map-from-CFLAGS-to-ASFLAGS.patch \ >> + file://0023-CVE-2026-19542.patch \ >> " >> B = "${WORKDIR}/build-${TARGET_SYS}" >> >> >> >> >> > Hi, > AS far as I know, we don't fix glibc through a patch to > Openembedded-core. Please send a patch to original glibc project's 2.43 > branch (or check their bug tracker to see if this is backported > already). Once merged, we maybe be able to update the recipe to point to > the latest 2.43 release. > > I would like someone to verify the above, but as I see there are no CVE > backport patches in the recipe. > > Thanks! > Adarsh Jagadish Kamini
That's true. Glibc CVE fixes always come via the upgrade along the branch. And I'd rather keep it that way. Thanks! -- Yoann Congal Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245038): https://lists.openembedded.org/g/openembedded-core/message/245038 Mute This Topic: https://lists.openembedded.org/mt/121072674/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
