Very strange bug: ld-linux.so crashes when trying to resolve passwd entries using nss_ldap. Only if it is not stripped (FEATURES=nostrip) and with glibc-2.3.4.20041021. (gdb) run Starting program: /home/chtephan/ld.so /bin/ls -l /mnt/server/home/ Program received signal SIGSEGV, Segmentation fault. 0x80005dfb in _dl_map_object_from_fd () (gdb) bt #0 0x80005dfb in _dl_map_object_from_fd () #1 0x80006a95 in _dl_map_object () #2 0x8000a648 in openaux () #3 0x8000baee in _dl_catch_error () #4 0x8000acd4 in _dl_map_object_deps () [ebuild R ] sys-libs/glibc-2.3.4.20041021 -build -debug -erandom -hardened -multilib +nls +nptl +nptlonly -pic -userlocales 0 kB [ebuild R ] net-libs/nss_ldap-220 +berkdb -debug 0 kB [ebuild R ] net-nds/openldap-2.1.30-r3 +berkdb +crypt -debug +gdbm -ipv6 +odbc +perl +readline +samba* +sasl +slp +ssl +tcpd 0 kB gcc-Version 3.4.2 20041025 (Gentoo Linux 3.4.2-r3, ssp-3.4.1-1, pie-8.7.6.5) GNU ld version 2.15.92.0.2 20040927 CFLAGS="-march=pentium3 -O2 -pipe" Perhaps someone has a clue, I manually stripped my ld-2.3.4.so for now. Reproducible: Always Steps to Reproduce:
please upgrade your nss_ldap to 226 and see if you can still produce this bug.
No, I'm sorry, but the problem is still there. I just recompiled my glibc-2.3.4.20041102 to have a ld-2.3.4.so with debugging info and there was that segfault again. "strip --strip-debug ld-2.3.4.so" makes it work again. I already used nss_ldap-226 since it was available. It is also happening with different nss_ldap dependencies (OpenLDAP 2.2 and 2.1, different cyrus-sasl plugins)
1. remove all ldap items from your nsswitch.conf 2. CFLAGS="-g -O1" FEATURES="keepwork nostrip" USE="debug" emerge glibc openldap nss_ldap 3. restart nscd (make sure it's running) 4. check that LDAP is working. 4. enable core dumps 5. run getent -s 'ldap' passwd 6. it should crash, and then run 'gdb `which getent` core' 7. in GDB, run 'bt' and post the full backtrace.
So, this is getting very interesting... I did a - backtrace with debug info (backtrace.txt) - disassembled the function in gdb (disas.txt) - did an objdump -drl (objdump.txt) - dumped the register contents (registers.txt) - and looked at the memory maps a) with an unstripped (and crashing) ld-2.3.4.so (memory-maps-unstripped.txt) b) with a stripped (and working) ld-2.3.4.so (memory-maps-stripped.txt) You can find these at http://www2.saout.de/glibc-segfault/ If you look at the backtrace you will see that _dl_map_object_from_fd crashes in line 1335, when it tries to modify __stack_prot: 1335: __stack_prot |= PROT_EXEC; /usr/lib/libcrypto.so.0.9.7 has the executable stack bit set. (BTW: clearing it explicitly using "execstack -c /usr/lib/libcrypto.so.0.9.7" makes the problem go away) /var/tmp/portage/glibc-2.3.4.20041102/work/glibc-2.3.3/elf/dl-load.c:1335 5822: 83 8b 14 ff ff ff 04 orl $0x4,0xffffff14(%ebx) ebx 0x41015fb4 1090609076 %ebx + $0xffffff14 = 0x41015ec8 (gdb) print &__stack_prot $1 = (int *) 0x41015ec8 This looks ok. But now take a look at the memory maps: stripped ld.so (working): 41000000-41015000 r-xp 00000000 07:00 412207 /mnt/tmp/lib/ld-2.3.4.so 41015000-41017000 rw-p 00014000 07:00 412207 /mnt/tmp/lib/ld-2.3.4.so <- here unstripped ld.so (crashing): 41000000-41015000 r-xp 00000000 07:00 410975 /mnt/tmp/lib/ld-2.3.4.so 41015000-41016000 r--p 00014000 07:00 410975 /mnt/tmp/lib/ld-2.3.4.so <- here 41016000-41017000 rw-p 00015000 07:00 410975 /mnt/tmp/lib/ld-2.3.4.so Whoops, readonly mapping?
This glibc bugzilla books looks similar, it might be the same problem: http://sources.redhat.com/bugzilla/show_bug.cgi?id=419
So to summarize: Unstripped /lib/ld-2.3.4.so has readonly memory mapping causing crashes when applications are linked with something that has an executable stack bit. Crypto: Does OpenSSL need executable stack?
No, it doesn't. That's why I manually removed it on a machine where I'm actually using NX. It's because openssl call gas manually and gas sets the executable stack bit in the object file if not explicitly disabled using --noexecstack (like gcc does).
Christophe: could you suggest a patch to fix up the openssl ebuild to remove the executable stack bit? Also, could you post up something to check in a vague automated fashion for other libraries that would be broken by the same issue?
*** Bug 76205 has been marked as a duplicate of this bug. ***
Sorry, it took so long. I don't quite understand then openssl build system (and I don't want to ;)). It seems the soulution is quite simple: Just add -Wa,--noexecstack to the CFLAGS on x86 (the other archs don't use inline assembly). Works for me.
in cvs.
