Bug 24900 - ld.so: Explicit loader invocation results in argv[0] in l_libname of main map
Summary: ld.so: Explicit loader invocation results in argv[0] in l_libname of main map
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: 2.31
: P3 normal
Target Milestone: 2.31
Assignee: Florian Weimer
Depends on:
Reported: 2019-08-12 14:30 UTC by Florian Weimer
Modified: 2021-10-26 12:26 UTC (History)
2 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2019-08-12 14:30:55 UTC
With an explicit loader invocation, the loader adds the main executable name (which is passed to the main function as argv[0]) to l_libname of the main map.  This is not what happens in default mode.  There, the string "" is used instead.

If possible, we should align the behavior for both modes, so that glibc testing without hardcoded paths becomes more realistic.
Comment 1 Sourceware Commits 2019-08-15 17:13:06 UTC
The master branch has been updated by Florian Weimer <fw@sourceware.org>:


commit 23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Aug 15 14:37:50 2019 +0200

    elf: Self-dlopen failure with explict loader invocation [BZ #24900]
    In case of an explicit loader invocation, ld.so essentially performs
    a dlopen call to load the main executable.  Since the pathname of
    the executable is known at this point, it gets stored in the link
    map.  In regular mode, the pathname is not known and "" is used
    As a result, if a program calls dlopen on the pathname of the main
    program, the dlopen call succeeds and returns a handle for the main
    map.  This results in an unnecessary difference between glibc
    testing (without --enable-hardcoded-path-in-tests) and production
    This commit discards the names when building the link map in
    _dl_new_object for the main executable, but it still determines
    the origin at this point in case of an explict loader invocation.
    The reason is that the specified pathname has to be used; the kernel
    has a different notion of the main executable.
Comment 2 Florian Weimer 2019-08-15 17:14:23 UTC
Fixed in glibc 2.31.
Comment 3 Florian Weimer 2019-08-27 06:59:54 UTC
The fix is incomplete because it does not cover PIE.  Patch posted:

Comment 4 Sourceware Commits 2019-10-04 21:01:01 UTC
The master branch has been updated by Florian Weimer <fw@sourceware.org>:


commit 2b26b084e4e4ba58a2ff9f8f8f14c9bca506bd59
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Oct 4 21:22:54 2019 +0200

    elf: Never use the file ID of the main executable [BZ #24900]
    If the loader is invoked explicitly and loads the main executable,
    it stores the file ID of the main executable in l_file_id.  This
    information is not available if the main excutable is loaded by the
    kernel, so this is another case where the two cases differ.
    This enhances commit 23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6
    ("elf: Self-dlopen failure with explict loader invocation
    [BZ #24900]").
    Reviewed-by: Carlos O'Donell <carlos@redhat.com>
    Reviewed-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Comment 5 Sourceware Commits 2019-10-17 06:55:26 UTC
The master branch has been updated by Florian Weimer <fw@sourceware.org>:


commit 7d3db434f910c23591f748a6d0ac3548af1048bb
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Oct 17 08:51:21 2019 +0200

    Rename and split elf/tst-dlopen-aout collection of tests
    From the beginning, elf/tst-dlopen-aout has exercised two different
    bugs: (a) failure to report errors for a dlopen of the executable
    itself in some cases (bug 24900) and (b) incorrect rollback of the
    TLS modid allocation in case of a dlopen failure (bug 16634).
    This commit replaces the test with elf/tst-dlopen-self for (a) and
    elf/tst-dlopen-tlsmodid for (b).  The latter tests use the
    elf/tst-dlopen-self binaries (or iconv) with dlopen, so they are
    no longer self-dlopen tests.
    Tested on x86_64-linux-gnu and i686-linux-gnu, with a toolchain that
    does not default to PIE.
Comment 6 Adhemerval Zanella 2021-10-08 13:53:55 UTC
Florian, has this bug being fixed by 2b26b084e4e4ba58a2ff9f8f8f14c9bca506bd59?
Comment 7 Florian Weimer 2021-10-26 12:26:34 UTC
Yes, it's fixed in glibc 2.31 as far as I can see.