This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/23462] New: Static binary with dynamic string tokens crashes.
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 27 Jul 2018 13:16:17 +0000
- Subject: [Bug dynamic-link/23462] New: Static binary with dynamic string tokens crashes.
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=23462
Bug ID: 23462
Summary: Static binary with dynamic string tokens crashes.
Product: glibc
Version: 2.29
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: carlos at redhat dot com
Target Milestone: ---
A static binary crashes when started with dynamic string tokens in
LD_LIBRARY_PATH.
For example:
LD_LIBRARY_PATH=/foo/'$LIB' ./elf/ldconfig
Segmentation fault (core dumped)
The problem is here:
elf/dl-load.c (_dl_init_paths):
751 #ifdef SHARED
752 /* This points to the map of the main object. */
753 l = GL(dl_ns)[LM_ID_BASE]._ns_loaded;
754 if (l != NULL)
We only load l within #ifdef SHARED, but later on we use it unconditionally in
the following call chain fillin_rpath -> expand_dynamic_string_token ->
DL_DST_REQUIRED.
Previously we had:
# 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 guarded against this case, but after:
commit d1d5471579eb0426671bf94f2d71e61dfb204c30
Author: Maciej W. Rozycki <macro@codesourcery.com>
Date: Sat Jun 22 00:39:42 2013 +0100
Remove dead DL_DST_REQ_STATIC code.
We removed it.
Maciej's work was specifically designed to make static/dynamic cases have
parity here, and so it just looks like an oversight that we don't
unconditionally set the link map.
The solution is to always set the link map l, and remove the 'if ((l) == NULL)'
because we are never NULL.
Interestingly coverity scan detected a logical problem here because it said if
l is ever NULL then we'll crash, and it was right.
I have a patch for this and it passes the above test. I'll submit it shortly.
--
You are receiving this mail because:
You are on the CC list for the bug.