Description of problem: When ldconfig is run and there are dynamic tokens (e.g. '$LIB') in the LD_LIBRARY_PATH, it segfaults due to a NULL 'struct link_map' pointer dereference. Version-Release number of selected component (if applicable): 2.26 / 28.fc27 How reproducible: 100% Steps to Reproduce: 1. LD_LIBRARY_PATH= ldconfig # OK 2. LD_LIBRARY_PATH=/foo/'$LIB' ldconfig # segfault Actual results: segfault Expected results: not segfault Additional info: (gdb) run Starting program: /usr/sbin/ldconfig Program received signal SIGSEGV, Segmentation fault. 0x00000000004860e3 in expand_dynamic_string_token (l=0x0, s=0x7fffffffd9b0 "/home/david/local/$LIB", is_path=1) at dl-load.c:379 379 total = DL_DST_REQUIRED (l, s, strlen (s), cnt); (gdb) bt #0 0x00000000004860e3 in expand_dynamic_string_token (l=0x0, s=0x7fffffffd9b0 "/home/david/local/$LIB", is_path=1) at dl-load.c:379 #1 0x00000000004863a5 in fillin_rpath (rpath=<optimized out>, rpath@entry=0x7fffffffd9b0 "/home/david/local/$LIB", result=0x6cda70, sep=sep@entry=0x4b50b7 ":;", check_trusted=0, what=what@entry=0x4a3137 "LD_LIBRARY_PATH", where=where@entry=0x0, l=0x0) at dl-load.c:446 #2 0x0000000000486962 in _dl_init_paths (llp=0x7fffffffe0b0 "/home/david/local/$LIB") at dl-load.c:812 #3 0x00000000004562e4 in _dl_non_dynamic_init () at dl-support.c:325 #4 0x00000000004572a3 in __libc_init_first (argc=argc@entry=1, argv=argv@entry=0x7fffffffdb88, envp=0x7fffffffdb98) at ../csu/init-first.c:74 #5 0x0000000000406c8e in __libc_start_main (main=0x400600 <main>, argc=1, argv=0x7fffffffdb88, init=0x4073c0 <__libc_csu_init>, fini=0x407450 <__libc_csu_fini>, rtld_fini=0x0, stack_end=0x7fffffffdb78) at ../csu/libc-start.c:244 #6 0x000000000040110a in _start () at ../sysdeps/x86_64/start.S:120 (gdb) print l $18 = (struct link_map *) 0x0 (gdb)
This looks like a real bug: * binary must be statically linked * must pass DSTs through to _dl_init_paths The problem is that we don't set l for static applications so this has never worked. With upstream's support for static link maps we will always have a non-NULL main linkmap. So I can clean this code up. I tested this fixes the issue: diff --git a/elf/dl-load.c b/elf/dl-load.c index c51e4b3718..348796c0a8 100644 --- a/elf/dl-load.c +++ b/elf/dl-load.c @@ -748,9 +748,10 @@ _dl_init_paths (const char *llp) max_dirnamelen = SYSTEM_DIRS_MAX_LEN; *aelem = NULL; -#ifdef SHARED /* This points to the map of the main object. */ l = GL(dl_ns)[LM_ID_BASE]._ns_loaded; + +#ifdef SHARED if (l != NULL) { assert (l->l_type != lt_loaded);
RHEL 7.6 has this guard which prevents failure: # define DL_DST_REQ_STATIC(l) \ if ((l) == NULL) \ { \ const char *origin = _dl_get_origin (); \ dst_len = (origin && origin != (char *) -1 ? strlen (origin) : 0); \ } \ else #endif Which was removed by Maciej's upstream changes precisely to get static link map parity with the shared case. commit d1d5471579eb0426671bf94f2d71e61dfb204c30 Author: Maciej W. Rozycki <macro> Date: Sat Jun 22 00:39:42 2013 +0100 Remove dead DL_DST_REQ_STATIC code. So it looks like an incomplete transition, where we missed setting 'l' outside of the #ifdef.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening and re-targeting for Fedora 29.
$ uname -a Linux xxxxxx 5.0.5-200.fc29.x86_64 #1 SMP Wed Mar 27 20:58:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux $ LD_LIBRARY_PATH=/foo/'$LIB' ldconfig Segmentation fault (core dumped)
It's not written here yet, but the issue can be reproduced with any statically linked PIE: $ cat > empty.c int main(void) { return 1; } $ gcc -static-pie empty.c -o empty $ file empty empty: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, for GNU/Linux 3.2.0, BuildID[sha1]=95e27090a4d7f3de5e632faf9cedbbd22a4afe57, not stripped, too many notes (256) $ ldd empty statically linked $ LD_LIBRARY_PATH=/foo/'$LIB' ./empty Erreur de segmentation (core dumped)
Reproduced on Fedora 30 (aarch64, which is the only Fedora 30 I have access to ATM): $ uname -a Linux xxxxxx 5.0.14-300.fc30.aarch64 #1 SMP Thu May 9 10:16:12 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux $ LD_LIBRARY_PATH=/foo/'$LIB' ldconfig Segmentation fault (core dumped)
(aside: I wasn't able to report ldconfig crash through abrt, I've opened the bug #1715110 regarding libreport and statically linked executable).
We are tracking this upstream and will fix it there.
This has been fixed upstream, and I'm going to backport the changes.
Fedora 34 and rawhide fixed. We are not going to fix Fedora 33. Thanks for your understanding.
Great, thanks! I'm using Fedora 34 now so it's fine as far as I'm concerned.