Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-107900

ppc64le, Conditional jump or move depends on uninitialised value in dlopen->...->strcmp

Linking RHIVOS CVEs to...Migration: Automation ...SWIFT: POC ConversionSync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • rhel-9.7
    • rhel-10.1, rhel-9.7
    • valgrind
    • None
    • valgrind-3.25.1-3.el9
    • No
    • Moderate
    • 1
    • rhel-pt-perf-tools
    • 26
    • 32
    • 3
    • False
    • False
    • Hide

      None

      Show
      None
    • No
    • PT PerfDebug 2025 S11
    • Release Note Not Required
    • Unspecified
    • Unspecified
    • Unspecified
    • ppc64le
    • None

      We've been observing a weird memcheck failure when executing gnutls upstream testsuite under valgrind for a while. Florian Weimer has suggested this looks like a valgrind bug. Unfortunately, I could not reproduce it through reasoning alone, and it's been very hard to detangle it from the gnutls internals without it disappearing like sand through the fingers, so reporting that took a lot of time. The resulting reproducer is still extremely fragile, but at least it's somewhat standalone and trimmed for your convenience.

      Original, unabridged code, linked for reference only:
      https://gitlab.com/gnutls/gnutls/-/blob/master/tests/pkcs11/distrust-after.c
      https://gitlab.com/gnutls/gnutls/-/blob/master/tests/pkcs11/pkcs11-mock3.c

      Standalone versions of both are provided in attachments.

      What were you trying to do that didn't work?

      execute distrust-after gnutls upstream test under valgrind on ppc64le

      What is the impact of this issue to you?

      frustration buildup, up to the point that it finally overcame the feeling of powerlessness to report, so here we are

      Please provide the package NVR for which the bug is seen:

      valgrind-3.25.1-1.el9.ppc64le
      glibc-2.34-221.el9.ppc64le
      gnutls-3.8.3-8.el9.ppc64le
      p11-kit-0.25.3-3.el9.ppc64le
      softhsm-2.6.1-11.el9.ppc64le
      openssl-3.5.1-3.el9.ppc64le

      How reproducible is this bug?:

      reliably run-to-run, but it's so sensitive to the tiniest of adjustments...

      Steps to reproduce

      1. # get a ppc64le
      2. # download standalone versions of distrust-after.c and pkcs11-mock3.c from the attachments
      3. dnf -y install gcc valgrind gnutls-devel p11-kit-devel softhsm glibc-debuginfo gnutls-debuginfo p11-kit-debuginfo softhsm-debuginfo
      4. cc -I/usr/include/p11-kit-1 -shared -Wl,-soname -Wl,libpkcs11mock3.so -o libpkcs11mock3.so pkcs11-mock3.c -O1
      5. cc -o distrust-after distrust-after.c -lgnutls
      6. valgrind --track-origins=yes ./distrust-after /usr/lib64/pkcs11/libsofthsm2.so $(realpath libpkcs11mock3.so) 

      Expected results

      no error (and there's a million subtlest ways to make it go away, it's a fragile one)

      Actual results

      ==231864== Conditional jump or move depends on uninitialised value(s)
      ==231864== at 0x4042590: strcmp (strcmp.S:76)
      ==231864== by 0x401BC37: _dl_name_match_p (dl-misc.c:69)
      ==231864== by 0x401CA37: dl_open_worker_begin (dl-open.c:553)
      ==231864== by 0x4002593: _dl_catch_exception (dl-catch.c:237)
      ==231864== by 0x401C5E3: dl_open_worker (dl-open.c:782)
      ==231864== by 0x4002593: _dl_catch_exception (dl-catch.c:237)
      ==231864== by 0x401DFDB: _dl_open (dl-open.c:903)
      ==231864== by 0x443D58F: dlopen_doit (dlopen.c:56)
      ==231864== by 0x4002593: _dl_catch_exception (dl-catch.c:237)
      ==231864== by 0x400276B: _dl_catch_error (dl-catch.c:256)
      ==231864== by 0x443CDF3: _dlerror_run (dlerror.c:138)
      ==231864== by 0x443D673: UnknownInlinedFun (dlopen.c:71)
      ==231864== by 0x443D673: dlopen@@GLIBC_2.34 (dlopen.c:81)
      

        1. distrust-after.c
          0.2 kB
          Alexander Sosedkin
        2. pkcs11-mock3.c
          4 kB
          Alexander Sosedkin

              rhn-engineering-mjw Mark Wielaard
              asosedki@redhat.com Alexander Sosedkin
              Mark Wielaard Mark Wielaard
              Martin Cermak Martin Cermak
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: