Bug 15378 - Segmentation fault when LD_LIBRARY_PATH contains (only) non-existings paths
Summary: Segmentation fault when LD_LIBRARY_PATH contains (only) non-existings paths
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-18 15:00 UTC by Bram
Modified: 2015-01-25 05:38 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Patch to add 'env_path_list' exception (509 bytes, application/aegis-patch)
2013-04-18 15:00 UTC, Bram
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bram 2013-04-18 15:00:07 UTC
Created attachment 6989 [details]
Patch to add 'env_path_list' exception

We get a segmentation fault when LD_LIBRARY_PATH contains only non-existings paths.
The segfault seems to happen only in combination with RPATH but we're not 100% sure if that is the only way to trigger this...

Test code that triggers it:
$ cat foo1.c
int foo1_lib1 = 5;

$ cat foo2.c
extern int foo1_lib1;
int foo2_lib2 = 6;

void func() {
	foo2_lib2 = foo1_lib1;
}

$ cat a.c
#include <stdio.h>
#include <unistd.h>
#include <dlfcn.h>

int main () {
	printf("A\n");
	sleep(5);
	printf("B\n");
	
 	dlopen("/tmp/glibc/libfoo2.so", RTLD_LAZY);
	printf("C\n");
}

$ cc -fPIC -o foo1.o -c foo1.c
$ cc -fPIC -Wl,-rpath=/usr/lib -shared -Wl,-soname,libfoo1.so -o libfoo1.so foo1.o 
$ cc -fPIC -o foo2.o -c foo2.c
$ cc -fPIC -Wl,-rpath=/usr/lib -L . -shared -Wl,-soname,libfoo2.so -o libfoo2.so foo2.o -l foo1

Now check that libfoo2.so is linked with libfoo1.so:
$ ldd libfoo2.so
	...
	libfoo1.so => not found
	...

Check the path of libdb.so.
On my system this is /usr/lib/libdb.so.2 => use -rpath=/usr/lib in the following commands.
If 'libdb.so' is located in another directory then the path in the following commands need to be changed:
$ cc -o a.out  a.c -ldl
$ cc -Wl,-rpath=/usr/lib -o a_rpath.out  a.c -ldl
$ cc -Wl,-rpath=/usr/lib,--enable-new-dtags -o a_rpath_runpath.out  a.c -ldl


Running it:
$ LD_LIBRARY_PATH=/non_existing_path ./a.out # => no segfault
$ LD_LIBRARY_PATH=/non_existing_path ./a_rpath.out # => segfault
$ LD_LIBRARY_PATH=/non_existing_path ./a_rpath_runpath.out # => no segfault


Note: this does not apperr to be reproducible on all systems...
* Testing this on a custom build system using glibc-2.7 shows the segfault on 'a_rpath.out'
* Testing this on a custom build system using glibc-2.13 shows the segfault on 'a_rpath.out'
* Testing this on a custom build system using glibc-2.17 shows the segfault on 'a_rpath.out'
* Testing this on Ubuntu 8.04 using glibc-2.7 shows no segfault on ''a_rpath.out' (no idea why)
* Testing this on Ubunutu 12.10 using glibc-2.15 shows the segfault on 'a_rpath.out'


Backtracing the segfault on glibc-2.17:
Core was generated by `./a_rpath.out'.
Program terminated with signal 11, Segmentation fault.
#0  open_path (name=name@entry=0xb756a28e "libfoo1.so", namelen=namelen@entry=11, secure=secure@entry=0, sps=sps@entry=0xb770df24 <env_path_list>, realname=realname@entry=0xbffdf714, 
    fbp=fbp@entry=0xbffdf71c, loader=0x9049028, whatcode=whatcode@entry=2, found_other_class=found_other_class@entry=0xbffdf713) at dl-load.c:2062
2062		sps->dirs = (void *) -1;
(gdb) bt
#0  open_path (name=name@entry=0xb756a28e "libfoo1.so", namelen=namelen@entry=11, secure=secure@entry=0, sps=sps@entry=0xb770df24 <env_path_list>, realname=realname@entry=0xbffdf714, 
    fbp=fbp@entry=0xbffdf71c, loader=0x9049028, whatcode=whatcode@entry=2, found_other_class=found_other_class@entry=0xbffdf713) at dl-load.c:2062
#1  0xb76f507c in _dl_map_object (loader=0x9049028, name=<optimized out>, type=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-2147483648, nsid=nsid@entry=0) at dl-load.c:2202
#2  0xb76f9998 in openaux (a=0xbffdfb08) at dl-deps.c:63
#3  0xb756b5d8 in __JCR_LIST__ () from /tmp/glibc/libfoo2.so
#4  0xb76f9950 in ?? () at dl-deps.c:84 from /ub/lib/ld-linux.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Looking in the code:
      if (sps != &rtld_search_dirs)
        sps->dirs = (void *) -1;

It fails on the assignment.
Printing 'sps', 'rtld_search_dirs', 'env_path_list' shows:

(gdb) print sps
$1 = (struct r_search_path_struct *) 0xb770df24 <env_path_list>
(gdb) print & rtld_search_dirs
$2 = (struct r_search_path_struct *) 0xb770df1c <rtld_search_dirs>
(gdb) print & env_path_list
$3 = (struct r_search_path_struct *) 0xb770df24 <env_path_list>

=> 'sps' is not equal to 'rtld_search_dirs' but 'sps' is equal to 'env_path_list'.

env_path_list is defined as: 
	static struct r_search_path_struct env_path_list attribute_relro;

=> it is set as 'attribute_relro'

Looking in the commit history shows:

commit 392a6b52656c1bb40305375b0ea9020455044f9d
author	Ulrich Drepper <drepper@redhat.com>	
	Thu, 15 Jan 2004 06:38:27 +0000 (06:38 +0000)

=> this commit added the 'attribute_relro' on 'env_path_list' and on 'rtld_search_dirs'

commit ecc1d0c301d97bdd540ff8d414a2eb4dcae51ea0
author	Ulrich Drepper <drepper@redhat.com>	
	Mon, 7 Feb 2005 23:52:23 +0000 (23:52 +0000)

=> this commit added the exception for updating 'sps->dirs'


We believe an exception for 'env_path_list' is also needed.
A patch for this is attached.
Comment 1 Bram 2013-04-22 07:56:17 UTC
I've seem to made a 'typo' in my bug report:

(In reply to comment #0)
> 
> Check the path of libdb.so.
> On my system this is /usr/lib/libdb.so.2 => use -rpath=/usr/lib in the
> following commands.
> If 'libdb.so' is located in another directory then the path in the following
> commands need to be changed:

This should read 'libdl' and not 'libdb'...
Comment 2 Siddhesh Poyarekar 2013-05-17 13:36:15 UTC
Thanks for the patch.  could you please post it on libc-alpha mailing list for review?  Please see the contribution checklist for guidelines:

http://sourceware.org/glibc/wiki/Contribution%20checklist
Comment 3 Hong Xu 2014-10-12 23:11:19 UTC
Have you submitted the patch yet? I am also experiencing this problem (see http://bugs.archlinux.org/task/38069#comment128530), and the attached patch here has fixed my issue.
Comment 4 Allan McRae 2015-01-25 05:38:37 UTC
commit 9317ea653afc26402387cac67042f9890af6add2
Author: Bram <bug_rh@spam.wizbit.be>
Date:   Thu Apr 18 16:50:49 2013 +0200

    Fix segmentation fault when LD_LIBRARY_PATH contains only non-existings paths