[Bug libc/15378] New: Segmentation fault when LD_LIBRARY_PATH contains (only) non-existings paths

["bug_rh at spam dot wizbit.be" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15378

             Bug #: 15378
           Summary: Segmentation fault when LD_LIBRARY_PATH contains
                    (only) non-existings paths
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bug_rh@spam.wizbit.be
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


Created attachment 6989
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6989
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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.