[Bug libc/4018] New: segfault in ld.so on amd64

[Bug libc/4018] New: segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

Hi.

ld.so in glibc 2.5 SIGSEGVs on GNU/kFreeBSD on amd64.
The patch bellow fixes it. 
Please, could check, whether it should be applied in general ?

Thanks

Petr

diff -u -r1.34 dl-machine.h
--- sysdeps/x86_64/dl-machine.h 27 Oct 2006 23:11:47 -0000      1.34
+++ sysdeps/x86_64/dl-machine.h 9 Feb 2007 17:45:03 -0000
@@ -286,7 +286,7 @@
       const Elf64_Sym *const refsym = sym;
 #endif
       struct link_map *sym_map = RESOLVE_MAP (&sym, version, r_type);
-      Elf64_Addr value = (sym == NULL ? 0
+      Elf64_Addr value = (sym_map == NULL ? 0
                          : (Elf64_Addr) sym_map->l_addr + sym->st_value);
 
 #if defined RTLD_BOOTSTRAP && !USE___THREAD

-- 
           Summary: segfault in ld.so on amd64
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: Petr dot Salinger at seznam dot cz
                CC: glibc-bugs at sources dot redhat dot com


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-09 19:23 -------
Test case on a _supported_ platform needed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2007-02-09 20:43 -------
> Test case on a _supported_ platform needed.

Please, compare with corresponding part in sysdeps/i386/dl-machine.h
It already contains:

      const Elf32_Sym *const refsym = sym;
      struct link_map *sym_map = RESOLVE_MAP (&sym, version, r_type);
      Elf32_Addr value = sym_map == NULL ? 0 : sym_map->l_addr + sym->st_value;




-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-09 20:48 -------
Show or test case or get lost.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2007-02-09 21:09 -------
> Show or test case or get lost.

>From elf/rtld.c:

#define RESOLVE_MAP(sym, version, flags) \
  ((*(sym))->st_shndx == SHN_UNDEF ? 0 : &bootstrap_map)

So sym_map can become NULL even if sym is not NULL.
After that sym_map (equal to NULL) can be dereferenced.


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-10 02:28 -------
Nonsense, that case must never happen.  This is exactly why I ask for a test case.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2007-02-12 09:56 -------
> Nonsense, that case must never happen. 

It happens on  _unsupported_ platform.
It could probably happen also on linux without __ASSUME_GETCWD_SYSCALL.
This way would be <posix/getcwd.c> used as fallback also on linux.

<posix/getcwd.c> uses  opendir()/readdir()/closedir(), they use
__libc_lock_* functions.  They are mapped to __pthread_mutex_* functions via

# define __libc_maybe_call(FUNC, ARGS, ELSE) \
  (__extension__ ({ __typeof (FUNC) *_fn = (FUNC); \
                    _fn != NULL ? (*_fn) ARGS : ELSE; }))


Output of  readelf -a elf/ld.so :

Relocation section '.rela.dyn'

00000011afa8  000b00000006 R_X86_64_GLOB_DAT 0000000000000000
__pthread_mutex_lock + 0
00000011afb8  000f00000006 R_X86_64_GLOB_DAT 0000000000000000
__pthread_mutex_init + 0
00000011afc8  001700000006 R_X86_64_GLOB_DAT 0000000000000000
__pthread_mutex_unlock + 0
00000011afd0  001b00000006 R_X86_64_GLOB_DAT 0000000000000000
__pthread_mutex_destro + 0

Relocation section '.rela.plt':

00000011b000  000b00000007 R_X86_64_JUMP_SLO 0000000000000000
__pthread_mutex_lock + 0
00000011b010  000f00000007 R_X86_64_JUMP_SLO 0000000000000000
__pthread_mutex_init + 0
00000011b028  001700000007 R_X86_64_JUMP_SLO 0000000000000000
__pthread_mutex_unlock + 0
00000011b030  001b00000007 R_X86_64_JUMP_SLO 0000000000000000
__pthread_mutex_destro + 0

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2007-02-12 11:33 -------
Then you have a bug in your kFreeBSD port.
ld.so really must not have any SHN_UNDEF relocations.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2007-02-13 08:25 -------
> Then you have a bug in your kFreeBSD port.
> ld.so really must not have any SHN_UNDEF relocations.

History comes in cycles. The same bug have been at least in RedHat 7.3 glibc:

readelf -a /lib/ld-2.2.5.so | grep mutex

000134f0  00001806 R_386_GLOB_DAT        00000000  __pthread_mutex_lock     
00013500  00002406 R_386_GLOB_DAT        00000000  __pthread_mutex_unlock   
000134cc  00001807 R_386_JUMP_SLOT       00000000  __pthread_mutex_lock     
000134d8  00002407 R_386_JUMP_SLOT       00000000  __pthread_mutex_unlock   
    24: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_mutex_lock
    36: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_mutex_unlock
   269: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_mutex_lock
   281: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_mutex_unlock




-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2007-02-13 08:30 -------
And?

These days we have _rtld_global._dl_rtld_{,un}lock_recursive, or better yet
opendir/readdir/closedir code you compile into ld.so (i.e. with IS_IN_rtld
defined) should use no locking at all - ld.so certainly isn't going to use
the same DIR object between multiple threads.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/4018] segfault in ld.so on amd64

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2007-02-13 08:41 -------
> And?

The only point  - there used to be  SHN_UNDEF  on _supported_ platform in the
past and it worked correctly.

> These days we have _rtld_global._dl_rtld_{,un}lock_recursive, or better yet
> opendir/readdir/closedir code you compile into ld.so (i.e. with IS_IN_rtld
> defined) should use no locking at all - ld.so certainly isn't going to use
> the same DIR object between multiple threads.

I used test for IS_IN_rtld in our getcwd, it simply will not fallback
to <posix/getcwd.c> in ld.so. Anyway, thanks for the hint.



-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.