[Bug dynamic-link/20107] New: LD segfault during relocation while processing non-lazy libraries

["sourceware-bugzilla at zulan dot net" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20107

            Bug ID: 20107
           Summary: LD segfault during relocation while processing
                    non-lazy libraries
           Product: glibc
           Version: 2.23
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: sourceware-bugzilla at zulan dot net
  Target Milestone: ---

Created attachment 9265
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9265&action=edit
minimal example to reproduce (part 1/4)

I ran across a segfault in ld-linux when used with the latest Intel compiler
16.03. I was able to reproduce this with a minimal example using the following
setup:

A statically linked shared library with -z now "libcore.so", that uses glibc
symbols (e.g. memmove)

A shared library "libuser.so" linked against said library.

A binary linked against -luser.

When the loader processes libcore.so (first, and in non-lazy fasion), it
segfaults during relocation of "memmove". It appears some internal structure is
not yet initialized:
     57406:     relocation processing: ./libcore.so
     57406:     symbol=memmove;  lookup in file=...test/ldseg/clean/a.out [0]
     57406:     symbol=memmove;  lookup in file=./libuser.so [0]
     57406:     symbol=memmove;  lookup in
file=...glibc/install/head-debug/lib/libc.so.6 [0]
     57406:     binding file ./libcore.so [0] to
...glibc/install/head-debug/lib/libc.so.6 [0]: normal symbol `memmove'

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaf4e851 in ?? ()
(gdb) bt
#0  0x00002aaaaaf4e851 in ?? ()
#1  0x00002aaaaaab6b8d in elf_machine_rela (skip_ifunc=0,
reloc_addr_arg=0x2aaaab45f500, version=0x0, sym=<optimized out>,
reloc=0x2aaaab25f2b0, map=0x2aaaaaad2958) at ../sysdeps/x86_64/dl-machine.h:315
#2  elf_dynamic_do_Rela (skip_ifunc=0, lazy=0, nrelative=0, relsize=96,
reladdr=46912504197808, map=0x2aaaaaad2958) at do-rel.h:170
#3  _dl_relocate_object (scope=0x2aaaaaad2cb0, reloc_mode=<optimized out>,
consider_profiling=consider_profiling@entry=0) at dl-reloc.c:258
#4  0x00002aaaaaaaf316 in dl_main (phdr=<optimized out>, phnum=<optimized out>,
user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2070
#5  0x00002aaaaaac141d in _dl_sysdep_start
(start_argptr=start_argptr@entry=0x7fffffffe4b0,
dl_main=dl_main@entry=0x2aaaaaaaccb1 <dl_main>) at ../elf/dl-sysdep.c:249
#6  0x00002aaaaaaafa92 in _dl_start_final (arg=0x7fffffffe4b0) at rtld.c:307
#7  _dl_start (arg=0x7fffffffe4b0) at rtld.c:413
#8  0x00002aaaaaaabac8 in _start () from
...glibc/install/head-debug/lib/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffe749 in ?? ()
#11 0x0000000000000000 in ?? ()

The contents of "sym" are:

$2 = {st_name = 32, st_info = 16 '\020', st_other = 0 '\000', st_shndx = 0,
st_value = 0, st_size = 0}

Without knowing details, it seems to me that st_value is not initialized and
the code jumps to the very beginning of glibc.so.

-- 
You are receiving this mail because:
You are on the CC list for the bug.