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

glibc: Avoid lazy binding failures during dlclose

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Normal Normal
    • rhel-8.10
    • rhel-8.8.0.z
    • glibc
    • None
    • glibc-2.28-241.el8
    • None
    • None
    • ZStream
    • rhel-sst-pt-libraries
    • ssg_platform_tools
    • 11
    • 13
    • 3
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • None
    • Approved Blocker
    • Bug Fix
    • Hide
      .The `glibc` `dlclose` function no longer causes lazy binding failures

      Previously, the `glibc` dynamic linker would not bind symbols to functions that were about to be unloaded by a `dlclose` call. As a consequence, applications could terminate with a lazy binding error when a referenced object was unloaded before a referencing object. With this update, the `glibc` dynamic linker now checks if both the referencing and referenced object are being unloaded and, if they are, performs symbol binding. As a result, applications no longer fail from lazy binding errors during `dlclose` calls.
      Show
      .The `glibc` `dlclose` function no longer causes lazy binding failures Previously, the `glibc` dynamic linker would not bind symbols to functions that were about to be unloaded by a `dlclose` call. As a consequence, applications could terminate with a lazy binding error when a referenced object was unloaded before a referencing object. With this update, the `glibc` dynamic linker now checks if both the referencing and referenced object are being unloaded and, if they are, performs symbol binding. As a result, applications no longer fail from lazy binding errors during `dlclose` calls.
    • Done
    • All
    • None

      Issue is described and commented in glibc: Lazy binding during dlclose may fail unnecessarily

      I'm treating this mostly as a glibc bug. The weak symbol is a GCC issue, but not the core problem.

      The patch below (against upstream) fixes the reproducer. Admittedly it's a bit silly.

      diff --git a/elf/dl-lookup.c b/elf/dl-lookup.c
      index 05f36a2507..ecc1896c9d 100644
      --- a/elf/dl-lookup.c
      +++ b/elf/dl-lookup.c
      @@ -366,8 +366,10 @@ do_lookup_x (const char *undef_name, unsigned int new_hash,
      {{ if ((type_class & ELF_RTYPE_CLASS_COPY) && map->l_type == lt_executable)}}
      {{ continue;}}
      {{ }}
      - /* Do not look into objects which are going to be removed. */
      - if (map->l_removed)
      + /* Do not look into objects which are going to be removed.
      {{+ References from a map that is under removal are allowed, to}}
      {{+ enable lazy binding during dlclose. */}}
      + if (map->l_removed && !undef_map->l_removed)
      {{ continue;}}
      {{ }}
      {{ /* Print some debugging info if wanted. */}}

      I think it's quite low-risk. If we are worried about undef_map being NULL for some reason, we could a check for that after backporting.

      Customer is using a patched rhel7 hotfix package and requests rhel7 and rhel8 backports.

              fweimer@redhat.com Florian Weimer
              rhn-support-pandrade Paulo Andrade
              Florian Weimer Florian Weimer
              Martin Coufal Martin Coufal
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: