| Message ID | 20260125161623.729884-1-peter.marko@siemens.com |
|---|---|
| State | Under Review |
| Delegated to: | Yoann Congal |
| Headers | show |
| Series | [scarthgap] glibc: stable 2.39 branch updates | expand |
On Sun Jan 25, 2026 at 5:16 PM CET, Peter Marko via lists.openembedded.org wrote: > From: Peter Marko <peter.marko@siemens.com> > > git log --oneline 58cbbd43fe82910cf8ae9008351b0b0665104500..ce65d944e38a20cb70af2a48a4b8aa5d8fabe1cc > ce65d944e3 (HEAD -> release/2.39/master, origin/release/2.39/master) posix: Reset wordexp_t fields with WRDE_REUSE (CVE-2025-15281 / BZ 33814) > 831f63b94c resolv: Fix NSS DNS backend for getnetbyaddr (CVE-2026-0915) > fb22fd3f5b memalign: reinstate alignment overflow check (CVE-2026-0861) > 10c0bcb3d3 support: Exit on consistency check failure in resolv_response_add_name > f47dd22366 support: Fix FILE * leak in check_for_unshare_hints in test-container > 4a53354eaf sprof: fix -Wformat warnings on 32-bit hosts > beb8267909 sprof: check pread size and offset for overflow > c07002038f getaddrinfo.c: Avoid uninitialized pointer access [BZ #32465] > ae5fb93559 nptl: Optimize trylock for high cache contention workloads (BZ #33704) > efff7cb659 ppc64le: Power 10 rawmemchr clobbers v20 (bug #33091) > f6becd8ae8 ppc64le: Restore optimized strncmp for power10 > 0daa4e46b8 ppc64le: Restore optimized strcmp for power10 > 28c1de6580 AArch64: Fix instability in AdvSIMD tan > 03d0393343 AArch64: Optimise SVE scalar callbacks > 0d05a895f1 aarch64: fix includes in SME tests > c1dc4412f8 aarch64: fix cfi directives around __libc_arm_za_disable > d60f15dc89 aarch64: tests for SME > d1d0d09e9e aarch64: clear ZA state of SME before clone and clone3 syscalls > dbe1904b7c aarch64: define macro for calling __libc_arm_za_disable > 58cf4aa421 aarch64: update tests for SME > 1b3bd9a9a6 aarch64: Disable ZA state of SME in setjmp and sigsetjmp > 38942a336b linux: Also check pkey_get for ENOSYS on tst-pkey (BZ 31996) > c74d59a656 aarch64: Do not link conform tests with -Wl,-z,force-bti (bug 33601) > 323ad087a1 x86: fix wmemset ifunc stray '!' (bug 33542) > > Testing Results: > Before After Diff > PASS 4926 4921 -5 > XPASS 4 4 0 > FAIL 223 229 +6 > XFAIL 16 16 0 > UNSUPPORTED 224 224 0 > > Changes in failed testcases: > > testcase-name before after > elf/tst-audit21 PASS FAIL > malloc/tst-malloc-too-large PASS FAIL > malloc/tst-malloc-too-large-malloc-check PASS FAIL > malloc/tst-malloc-too-large-malloc-hugetlb1 PASS FAIL > malloc/tst-malloc-too-large-malloc-hugetlb2 PASS FAIL > malloc/tst-malloc-too-large-mcheck PASS FAIL Hello Peter, Those test results show a clear regression (6 PASS->FAIL transistions). I noticed that the same tests have been fixed with the whinlatter upgrade: https://lore.kernel.org/openembedded-core/c5401d89c51fe73d93afc73d73cb0f93c00bbca7.1769845858.git.yoann.congal@smile.fr/ I'm not familiar with the glibc stable policy but shouldn't we wait the next cycle to get the fix for those tests and avoid triggering this regression in the meantime? What do you think? > Signed-off-by: Peter Marko <peter.marko@siemens.com> > --- > meta/recipes-core/glibc/glibc-version.inc | 2 +- > meta/recipes-core/glibc/glibc_2.39.bb | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc > index 2ca15711587..03a8e5d01e3 100644 > --- a/meta/recipes-core/glibc/glibc-version.inc > +++ b/meta/recipes-core/glibc/glibc-version.inc > @@ -1,6 +1,6 @@ > SRCBRANCH ?= "release/2.39/master" > PV = "2.39+git" > -SRCREV_glibc ?= "58cbbd43fe82910cf8ae9008351b0b0665104500" > +SRCREV_glibc ?= "ce65d944e38a20cb70af2a48a4b8aa5d8fabe1cc" > SRCREV_localedef ?= "cba02c503d7c853a38ccfb83c57e343ca5ecd7e5" > > GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" > diff --git a/meta/recipes-core/glibc/glibc_2.39.bb b/meta/recipes-core/glibc/glibc_2.39.bb > index ff6c8f3b437..7958d64eed1 100644 > --- a/meta/recipes-core/glibc/glibc_2.39.bb > +++ b/meta/recipes-core/glibc/glibc_2.39.bb > @@ -18,7 +18,7 @@ easier access for another. 'ASLR bypass itself is not a vulnerability.'" > > CVE_STATUS_GROUPS += "CVE_STATUS_STABLE_BACKPORTS" > CVE_STATUS_STABLE_BACKPORTS = "CVE-2024-2961 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 CVE-2025-0395 \ > - CVE-2025-4802 CVE-2025-5702 CVE-2025-8058" > + CVE-2025-4802 CVE-2025-5702 CVE-2025-8058 CVE-2025-15281 CVE-2026-0861 CVE-2026-0915" > CVE_STATUS_STABLE_BACKPORTS[status] = "cpe-stable-backport: fix available in used git hash" > > DEPENDS += "gperf-native bison-native"
Hello Peter, We sometimes see regressions in glibc test runs depending on the local environment. In such cases, it can help to re-trigger the tests to check whether the failures are consistently reproducible. It may also be useful to cross-check the results with autobuilder runs, which generally provide a more stable baseline before concluding on regressions. Thanks, Hemanth
Hello, On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via lists.openembedded.org wrote: > Hello Peter, (Yoann here) > We sometimes see regressions in glibc test runs depending on the local > environment. In such cases, it can help to re-trigger the tests to > check whether the failures are consistently reproducible. It may also > be useful to cross-check the results with autobuilder runs, which > generally provide a more stable baseline before concluding on > regressions. I'm willing to test this on the autobuilder. But I never done that... Any pointer? Where do I get the nice test report with the comparison to the previous version? Thanks!
> -----Original Message----- > From: openembedded-core@lists.openembedded.org <openembedded- > core@lists.openembedded.org> On Behalf Of Yoann Congal via > lists.openembedded.org > Sent: Friday, February 6, 2026 7:48 > To: Hemanth.KumarMD@windriver.com; openembedded- > core@lists.openembedded.org > Subject: Re: [OE-core] [scarthgap][PATCH] glibc: stable 2.39 branch updates > > Hello, > > On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via > lists.openembedded.org wrote: > > Hello Peter, > > (Yoann here) > > > We sometimes see regressions in glibc test runs depending on the local > > environment. In such cases, it can help to re-trigger the tests to > > check whether the failures are consistently reproducible. It may also > > be useful to cross-check the results with autobuilder runs, which > > generally provide a more stable baseline before concluding on > > regressions. I am planning to run the testsuites again during weekend. I also find it weird that every update shows different "before" results than previous one showin in "after" result. Not sure if it's flakiness or local conditions like CPU overload at time of running tests. > > I'm willing to test this on the autobuilder. But I never done that... > Any pointer? Where do I get the nice test report with the comparison to > the previous version? The tests are run via "bitbake glibc-testsuite -c check" The comparison table is created manually from task logfile. Basic testcase changes can be extracted from the same file. New/Removed tests need to be extracted from result files, bit of manual work. > > Thanks! > -- > Yoann Congal > Smile ECS
On 06-02-2026 12:17 pm, Yoann Congal wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hello, > > On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via lists.openembedded.org wrote: >> Hello Peter, > (Yoann here) > >> We sometimes see regressions in glibc test runs depending on the local >> environment. In such cases, it can help to re-trigger the tests to >> check whether the failures are consistently reproducible. It may also >> be useful to cross-check the results with autobuilder runs, which >> generally provide a more stable baseline before concluding on >> regressions. > I'm willing to test this on the autobuilder. But I never done that... > Any pointer? Where do I get the nice test report with the comparison to > the previous version? Hello Yoann, You can trigger a *qemux86-64-tc* build with this patch applied. Once the build completes, the corresponding results link will be available in the published artifacts. example: https://valkyrie.yocto.io/pub/non-release/20260206-8/testresults/qemux86-64-tc/ The *qemux86-64-tc* build artifacts include the |test-results.json| file. You can compare this against any recent successful *qemux86-64-tc* autobuilder run as the baseline. Hope this helps. Thanks, Hemanth > > Thanks! > -- > Yoann Congal > Smile ECS >
Le ven. 6 févr. 2026 à 09:19, Hemanth Kumar M D < Hemanth.KumarMD@windriver.com> a écrit : > > On 06-02-2026 12:17 pm, Yoann Congal wrote: > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hello, > > On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via lists.openembedded.org wrote: > > Hello Peter, > > (Yoann here) > > > We sometimes see regressions in glibc test runs depending on the local > environment. In such cases, it can help to re-trigger the tests to > check whether the failures are consistently reproducible. It may also > be useful to cross-check the results with autobuilder runs, which > generally provide a more stable baseline before concluding on > regressions. > > I'm willing to test this on the autobuilder. But I never done that... > Any pointer? Where do I get the nice test report with the comparison to > the previous version? > > > Hello Yoann, > > You can trigger a *qemux86-64-tc* build with this patch applied. Once the build completes, > the corresponding results link will be available in the published artifacts. > > example: https://valkyrie.yocto.io/pub/non-release/20260206-8/testresults/qemux86-64-tc/ > > The *qemux86-64-tc* build artifacts include the test-results.json file. You can compare this > against any recent successful *qemux86-64-tc* autobuilder run as the baseline. > > Hope this helps. > > That does! Thanks! The result from my first run of this branch (with this patch) shows no malloc failure: https://valkyrie.yocto.io/pub/non-release/20260203-124/testresults/qemux86-64-tc/testresults.json So, what I plan to do: Take this patch into my branch, test it when the branch is ready and add this info to the commit message. Thanks, > Hemanth > > Thanks! > -- > Yoann Congal > Smile ECS > > > -- > Regards, > Hemanth Kumar M D > >
On Fri, 2026-02-06 at 07:42 +0000, Peter Marko via lists.openembedded.org wrote: > > On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via > > lists.openembedded.org wrote: > > > Hello Peter, > > > > (Yoann here) > > > > > We sometimes see regressions in glibc test runs depending on the local > > > environment. In such cases, it can help to re-trigger the tests to > > > check whether the failures are consistently reproducible. It may also > > > be useful to cross-check the results with autobuilder runs, which > > > generally provide a more stable baseline before concluding on > > > regressions. > > I am planning to run the testsuites again during weekend. > I also find it weird that every update shows different "before" results than previous one showin in "after" result. > Not sure if it's flakiness or local conditions like CPU overload at time of running tests. > For context, many of the 'toolchain' testsuites have some flaky tests in them and we don't always see consistent output. For example, the 5.0.14 regression report mentions: https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.14/testresults/testresult-regressions-report.txt Regression: oeselftest_almalinux-8.10_qemuarm_20251014024649 oeselftest_almalinux-9.7_qemuarm_20251118011611 Total: 3 new regression(s): 1 regression(s) for ptestresult.gcc-libstdc++-v3-user ptestresult.gcc-libstdc++-v3-user.30_threads/async/async.cc execution test: PASS -> FAIL 2 regression(s) for ptestresult.glibc-user ptestresult.glibc-user.misc/tst-linux-mremap1: UNSUPPORTED -> FAIL ptestresult.glibc-user.misc/tst-pidfd: UNSUPPORTED -> FAIL or: 5 regression(s) for ptestresult.glibc ptestresult.glibc.elf/ifuncmain8: PASS -> No matching test result ptestresult.glibc.elf/tst-tls20: PASS -> FAIL ptestresult.glibc.iconvdata/mtrace-tst-loading: PASS -> FAIL ptestresult.glibc.iconvdata/tst-loading: PASS -> FAIL ptestresult.glibc.nptl/tst-thread-affinity-pthread: PASS -> FAIL over time we've been trying to investigate and resolve these kinds of issues but we're obviously not there yet. I can say we've made big improvements, you can see it in the numbers, e.g. comparing: https://downloads.yoctoproject.org/releases/yocto/yocto-4.0/testreport.txt - 142,413 failures https://downloads.yoctoproject.org/releases/yocto/milestones/yocto-5.3_M3/testreport.txt 1,636 failures which shows a definite improvement! The number of flaky test results has also decreased but is obviously not as easy to measure. We have a policy with ptests and rust of no failures. We're trying to get there with gcc/binutils/glibc/ltp. The test results are stored in the testresults.json files and resulttool knows how to generate reports and compare files for regression reports. The plus side of the autobuilder results is that we have a long baseline for comparison and a relatively stbale testing environment which should be consistent. Cheers, Richard
> -----Original Message----- > From: Yoann Congal <yoann.congal@smile.fr> > Sent: Thursday, February 5, 2026 18:09 > To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; > openembedded-core@lists.openembedded.org > Subject: Re: [OE-core][scarthgap][PATCH] glibc: stable 2.39 branch updates > > On Sun Jan 25, 2026 at 5:16 PM CET, Peter Marko via lists.openembedded.org > wrote: > > From: Peter Marko <peter.marko@siemens.com> > > > > git log --oneline > 58cbbd43fe82910cf8ae9008351b0b0665104500..ce65d944e38a20cb70af2a48a4b8 > aa5d8fabe1cc > > ce65d944e3 (HEAD -> release/2.39/master, origin/release/2.39/master) posix: > Reset wordexp_t fields with WRDE_REUSE (CVE-2025-15281 / BZ 33814) > > 831f63b94c resolv: Fix NSS DNS backend for getnetbyaddr (CVE-2026-0915) > > fb22fd3f5b memalign: reinstate alignment overflow check (CVE-2026-0861) > > 10c0bcb3d3 support: Exit on consistency check failure in > resolv_response_add_name > > f47dd22366 support: Fix FILE * leak in check_for_unshare_hints in test- > container > > 4a53354eaf sprof: fix -Wformat warnings on 32-bit hosts > > beb8267909 sprof: check pread size and offset for overflow > > c07002038f getaddrinfo.c: Avoid uninitialized pointer access [BZ #32465] > > ae5fb93559 nptl: Optimize trylock for high cache contention workloads (BZ > #33704) > > efff7cb659 ppc64le: Power 10 rawmemchr clobbers v20 (bug #33091) > > f6becd8ae8 ppc64le: Restore optimized strncmp for power10 > > 0daa4e46b8 ppc64le: Restore optimized strcmp for power10 > > 28c1de6580 AArch64: Fix instability in AdvSIMD tan > > 03d0393343 AArch64: Optimise SVE scalar callbacks > > 0d05a895f1 aarch64: fix includes in SME tests > > c1dc4412f8 aarch64: fix cfi directives around __libc_arm_za_disable > > d60f15dc89 aarch64: tests for SME > > d1d0d09e9e aarch64: clear ZA state of SME before clone and clone3 syscalls > > dbe1904b7c aarch64: define macro for calling __libc_arm_za_disable > > 58cf4aa421 aarch64: update tests for SME > > 1b3bd9a9a6 aarch64: Disable ZA state of SME in setjmp and sigsetjmp > > 38942a336b linux: Also check pkey_get for ENOSYS on tst-pkey (BZ 31996) > > c74d59a656 aarch64: Do not link conform tests with -Wl,-z,force-bti (bug 33601) > > 323ad087a1 x86: fix wmemset ifunc stray '!' (bug 33542) > > > > Testing Results: > > Before After Diff > > PASS 4926 4921 -5 > > XPASS 4 4 0 > > FAIL 223 229 +6 > > XFAIL 16 16 0 > > UNSUPPORTED 224 224 0 > > > > Changes in failed testcases: > > > > testcase-name before after > > elf/tst-audit21 PASS FAIL > > malloc/tst-malloc-too-large PASS FAIL > > malloc/tst-malloc-too-large-malloc-check PASS FAIL > > malloc/tst-malloc-too-large-malloc-hugetlb1 PASS FAIL > > malloc/tst-malloc-too-large-malloc-hugetlb2 PASS FAIL > > malloc/tst-malloc-too-large-mcheck PASS FAIL > > Hello Peter, > > Those test results show a clear regression (6 PASS->FAIL > transistions). > > I noticed that the same tests have been fixed with the whinlatter > upgrade: > https://lore.kernel.org/openembedded- > core/c5401d89c51fe73d93afc73d73cb0f93c00bbca7.1769845858.git.yoann.congal > @smile.fr/ > > I'm not familiar with the glibc stable policy but shouldn't we wait the > next cycle to get the fix for those tests and avoid triggering this > regression in the meantime? > > What do you think? I have bisected the problem to following commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=fb22fd3f5b415dd4cd6f7b5741c2f0412374e242 When reverting just the test change from there (keeping CVE fix), the 5 malloc tests succeed. So from this point of view, we could look at this as regression of the testsuite, or adding new failing tests without failing the already present ones. Peter > > > Signed-off-by: Peter Marko <peter.marko@siemens.com> > > --- > > meta/recipes-core/glibc/glibc-version.inc | 2 +- > > meta/recipes-core/glibc/glibc_2.39.bb | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes- > core/glibc/glibc-version.inc > > index 2ca15711587..03a8e5d01e3 100644 > > --- a/meta/recipes-core/glibc/glibc-version.inc > > +++ b/meta/recipes-core/glibc/glibc-version.inc > > @@ -1,6 +1,6 @@ > > SRCBRANCH ?= "release/2.39/master" > > PV = "2.39+git" > > -SRCREV_glibc ?= "58cbbd43fe82910cf8ae9008351b0b0665104500" > > +SRCREV_glibc ?= "ce65d944e38a20cb70af2a48a4b8aa5d8fabe1cc" > > SRCREV_localedef ?= "cba02c503d7c853a38ccfb83c57e343ca5ecd7e5" > > > > GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" > > diff --git a/meta/recipes-core/glibc/glibc_2.39.bb b/meta/recipes- > core/glibc/glibc_2.39.bb > > index ff6c8f3b437..7958d64eed1 100644 > > --- a/meta/recipes-core/glibc/glibc_2.39.bb > > +++ b/meta/recipes-core/glibc/glibc_2.39.bb > > @@ -18,7 +18,7 @@ easier access for another. 'ASLR bypass itself is not a > vulnerability.'" > > > > CVE_STATUS_GROUPS += "CVE_STATUS_STABLE_BACKPORTS" > > CVE_STATUS_STABLE_BACKPORTS = "CVE-2024-2961 CVE-2024-33599 > CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 CVE-2025-0395 \ > > - CVE-2025-4802 CVE-2025-5702 CVE-2025-8058" > > + CVE-2025-4802 CVE-2025-5702 CVE-2025-8058 CVE-2025-15281 CVE- > 2026-0861 CVE-2026-0915" > > CVE_STATUS_STABLE_BACKPORTS[status] = "cpe-stable-backport: fix > available in used git hash" > > > > DEPENDS += "gperf-native bison-native" > > > -- > Yoann Congal > Smile ECS
diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc index 2ca15711587..03a8e5d01e3 100644 --- a/meta/recipes-core/glibc/glibc-version.inc +++ b/meta/recipes-core/glibc/glibc-version.inc @@ -1,6 +1,6 @@ SRCBRANCH ?= "release/2.39/master" PV = "2.39+git" -SRCREV_glibc ?= "58cbbd43fe82910cf8ae9008351b0b0665104500" +SRCREV_glibc ?= "ce65d944e38a20cb70af2a48a4b8aa5d8fabe1cc" SRCREV_localedef ?= "cba02c503d7c853a38ccfb83c57e343ca5ecd7e5" GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" diff --git a/meta/recipes-core/glibc/glibc_2.39.bb b/meta/recipes-core/glibc/glibc_2.39.bb index ff6c8f3b437..7958d64eed1 100644 --- a/meta/recipes-core/glibc/glibc_2.39.bb +++ b/meta/recipes-core/glibc/glibc_2.39.bb @@ -18,7 +18,7 @@ easier access for another. 'ASLR bypass itself is not a vulnerability.'" CVE_STATUS_GROUPS += "CVE_STATUS_STABLE_BACKPORTS" CVE_STATUS_STABLE_BACKPORTS = "CVE-2024-2961 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 CVE-2025-0395 \ - CVE-2025-4802 CVE-2025-5702 CVE-2025-8058" + CVE-2025-4802 CVE-2025-5702 CVE-2025-8058 CVE-2025-15281 CVE-2026-0861 CVE-2026-0915" CVE_STATUS_STABLE_BACKPORTS[status] = "cpe-stable-backport: fix available in used git hash" DEPENDS += "gperf-native bison-native"