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

glibc: Add workaround for certain dynamic TLS usage in interposed malloc [rhel-8.10.z]

XMLWordPrintable

    • glibc-2.28-251.el8_10.4
    • None
    • None
    • 2
    • sst_pt_libraries
    • ssg_platform_tools
    • 1
    • Yes
    • Red Hat Enterprise Linux
    • SST PT Libraries Sprint 7, SST PT Libraries Sprint 8
    • Bug Fix
    • Hide
      .`glibc` dynamic linker prevents reentrant `malloc` calls made by applications using TLS access from custom `malloc` implementations

      Some applications provide a custom `malloc` dynamic memory allocation implementation that uses global-dynamic thread-local storage (TLS) instead of initial-exec TLS. Previously, applications with bundled `malloc` calls that use global-dynamic TLS could experience reentrant calls into the application's `malloc` subsystem. As a consequence, the application `malloc` call crashed due to stack exhaustion or unexpected state of internal data structures.

      With the release of the link:https://access.redhat.com/errata/RHBA-2024:5834[RHBA-2024:5834] advisory, the `glibc` dynamic linker detects TLS access from custom `malloc` implementations. If a TLS access during a `malloc` call is detected, further calls during TLS processing are skipped, and reentrant `malloc` calls are prevented.
      Show
      .`glibc` dynamic linker prevents reentrant `malloc` calls made by applications using TLS access from custom `malloc` implementations Some applications provide a custom `malloc` dynamic memory allocation implementation that uses global-dynamic thread-local storage (TLS) instead of initial-exec TLS. Previously, applications with bundled `malloc` calls that use global-dynamic TLS could experience reentrant calls into the application's `malloc` subsystem. As a consequence, the application `malloc` call crashed due to stack exhaustion or unexpected state of internal data structures. With the release of the link: https://access.redhat.com/errata/RHBA-2024:5834 [ RHBA-2024 :5834] advisory, the `glibc` dynamic linker detects TLS access from custom `malloc` implementations. If a TLS access during a `malloc` call is detected, further calls during TLS processing are skipped, and reentrant `malloc` calls are prevented.
    • Done
    • None

      This is a clone of issue RHEL-39992 to use for version rhel-8.10.z
      –
      Original description:
      Upstream has merged a compatibility enhancement after the fix for RHEL-2123, which we should backport as well:

      commit afe42e935b3ee97bac9a7064157587777259c60e
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Jun 3 10:49:40 2024 +0200

    elf: Avoid some free (NULL) calls in _dl_update_slotinfo
    
    This has been confirmed to work around some interposed mallocs.  Here
    is a discussion of the impact test ust/libc-wrapper/test_libc-wrapper
    in lttng-tools:
    
      New TLS usage in libgcc_s.so.1, compatibility impact
      <https://inbox.sourceware.org/libc-alpha/8734v1ieke.fsf@oldenburg.str.redhat.com/>
    
    Reportedly, this patch also papers over a similar issue when tcmalloc
    2.9.1 is not compiled with -ftls-model=initial-exec.  Of course the
    goal really should be to compile mallocs with the initial-exec TLS
    model, but this commit appears to be a useful interim workaround.
    
    Fixes commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow
    tls access after dlopen [BZ #19924]").
    
    Reviewed-by: Carlos O'Donell <carlos@redhat.com>

            xmcoufal Martin Coufal
            watson-automation Watson Automation
            Patsy Griffin Patsy Griffin
            Martin Coufal Martin Coufal
            Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: