Bug 1609351 - glibc: ldconfig segfaults when dynamic tokens are in LD_LIBRARY_PATH
Summary: glibc: ldconfig segfaults when dynamic tokens are in LD_LIBRARY_PATH
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-27 16:53 UTC by David M. Lloyd
Modified: 2021-05-18 15:57 UTC (History)
10 users (show)

Fixed In Version: glibc-2.33-5.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 13:21:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Sourceware 23462 0 None None None 2019-05-29 14:29:40 UTC

Internal Links: 1934162

Description David M. Lloyd 2018-07-27 16:53:19 UTC
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)

Comment 2 Carlos O'Donell 2018-07-27 18:21:28 UTC
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);

Comment 3 Carlos O'Donell 2018-07-27 18:24:51 UTC
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.

Comment 4 Ben Cotton 2018-11-27 14:54:27 UTC
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.

Comment 5 Ben Cotton 2019-05-02 19:48:14 UTC
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.

Comment 6 Ben Cotton 2019-05-28 23:45:46 UTC
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.

Comment 7 David M. Lloyd 2019-05-29 14:30:33 UTC
Reopening and re-targeting for Fedora 29.

Comment 8 David M. Lloyd 2019-05-29 14:31:34 UTC
$ 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)

Comment 9 Yann Droneaud 2019-05-29 14:44:41 UTC
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)

Comment 10 David M. Lloyd 2019-05-29 15:29:41 UTC
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)

Comment 11 Yann Droneaud 2019-05-29 15:44:18 UTC
(aside: I wasn't able to report ldconfig crash through abrt, I've opened the bug #1715110 regarding libreport and statically linked executable).

Comment 12 Florian Weimer 2019-10-08 14:05:07 UTC
We are tracking this upstream and will fix it there.

Comment 13 Florian Weimer 2021-03-16 10:05:12 UTC
This has been fixed upstream, and I'm going to backport the changes.

Comment 14 Florian Weimer 2021-05-18 13:21:05 UTC
Fedora 34 and rawhide fixed. We are not going to fix Fedora 33. Thanks for your understanding.

Comment 15 David M. Lloyd 2021-05-18 15:57:51 UTC
Great, thanks! I'm using Fedora 34 now so it's fine as far as I'm concerned.


Note You need to log in before you can comment on or make changes to this bug.