[prev in list] [next in list] [prev in thread] [next in thread]
List: nssldap
Subject: [nssldap] nss_ldap crash in CentOS 5
From: Stephen Roylance <StephenRoylance () mass ! rr ! com>
Date: 2008-03-19 20:59:51
Message-ID: 47E17EC7.6070703 () mass ! rr ! com
[Download RAW message or body]
I'm running CentOS 5 with nss_ldap package nss_ldap-253-5.el5. Our LDAP
server is an AD domain, with SSL enabled on all the domain controllers.
I've discovered that one group in AD causes nss_ldap to fail whenever
running id or groups on a user that is a member. The failure results in
this output:
*** glibc detected *** id: realloc(): invalid next size: 0x08e3bbc0 ***
======= Backtrace: =========
/lib/libc.so.6[0x9da390]
/lib/libc.so.6(realloc+0xfe)[0x9db21e]
/lib/libnss_ldap.so.2[0x37c16c]
/lib/libnss_ldap.so.2[0x37c8a6]
/lib/libnss_ldap.so.2(_nss_ldap_getbyname+0xbc)[0x37b16c]
/lib/libnss_ldap.so.2(_nss_ldap_getgrgid_r+0x78)[0x37cb08]
/lib/libc.so.6(getgrgid_r+0xa3)[0x9fd783]
/lib/libc.so.6(getgrgid+0x78)[0x9fcf78]
id[0x8049b14]
/lib/libc.so.6(__libc_start_main+0xdc)[0x986dec]
id[0x8048de1]
======= Memory map: ========
00110000-00114000 r-xp 00000000 fd:00 1795238 /lib/libnss_dns-2.5.so
00114000-00115000 r-xp 00003000 fd:00 1795238 /lib/libnss_dns-2.5.so
00115000-00116000 rwxp 00004000 fd:00 1795238 /lib/libnss_dns-2.5.so
0035d000-0063c000 r-xp 00000000 fd:00 1796028 /lib/libnss_ldap-2.5.so
0063c000-00654000 rwxp 002de000 fd:00 1796028 /lib/libnss_ldap-2.5.so
00654000-00662000 rwxp 00654000 00:00 0
0094f000-00968000 r-xp 00000000 fd:00 1795239 /lib/ld-2.5.so
00968000-00969000 r-xp 00019000 fd:00 1795239 /lib/ld-2.5.so
00969000-0096a000 rwxp 0001a000 fd:00 1795239 /lib/ld-2.5.so
00971000-00aab000 r-xp 00000000 fd:00 1795241 /lib/libc-2.5.so
00aab000-00aad000 r-xp 0013a000 fd:00 1795241 /lib/libc-2.5.so
00aad000-00aae000 rwxp 0013c000 fd:00 1795241 /lib/libc-2.5.so
00aae000-00ab1000 rwxp 00aae000 00:00 0
00ab3000-00ab5000 r-xp 00000000 fd:00 1795420 /lib/libdl-2.5.so
00ab5000-00ab6000 r-xp 00001000 fd:00 1795420 /lib/libdl-2.5.so
00ab6000-00ab7000 rwxp 00002000 fd:00 1795420 /lib/libdl-2.5.so
00afb000-00b36000 r-xp 00000000 fd:00 1795435 /lib/libsepol.so.1
00b36000-00b37000 rwxp 0003a000 fd:00 1795435 /lib/libsepol.so.1
00b37000-00b41000 rwxp 00b37000 00:00 0
00b43000-00b58000 r-xp 00000000 fd:00 1795440 /lib/libselinux.so.1
00b58000-00b5a000 rwxp 00015000 fd:00 1795440 /lib/libselinux.so.1
00b7c000-00b87000 r-xp 00000000 fd:00 1797445
/lib/libgcc_s-4.1.2-20070626.so.1
00b87000-00b88000 rwxp 0000a000 fd:00 1797445
/lib/libgcc_s-4.1.2-20070626.so.1
00c7e000-00c7f000 r-xp 00c7e000 00:00 0 [vdso]
00cbf000-00cce000 r-xp 00000000 fd:00 1797454 /lib/libresolv-2.5.so
00cce000-00ccf000 r-xp 0000e000 fd:00 1797454 /lib/libresolv-2.5.so
00ccf000-00cd0000 rwxp 0000f000 fd:00 1797454 /lib/libresolv-2.5.so
00cd0000-00cd2000 rwxp 00cd0000 00:00 0
00cd4000-00cd6000 r-xp 00000000 fd:00 1797455 /lib/libcom_err.so.2.1
00cd6000-00cd7000 rwxp 00001000 fd:00 1797455 /lib/libcom_err.so.2.1
00d21000-00d2a000 r-xp 00000000 fd:00 1795240 /lib/libnss_files-2.5.so
00d2a000-00d2b000 r-xp 00008000 fd:00 1795240 /lib/libnss_files-2.5.so
00d2b000-00d2c000 rwxp 00009000 fd:00 1795240 /lib/libnss_files-2.5.so
08048000-0804d000 r-xp 00000000 fd:00 3272551 /usr/bin/id
0804d000-0804e000 rw-p 00004000 fd:00 3272551 /usr/bin/id
08de7000-08e74000 rw-p 08de7000 00:00 0
b7c00000-b7c21000 rw-p b7c00000 00:00 0
b7c21000-b7d00000 ---p b7c21000 00:00 0
b7dcf000-b7fcf000 r--p 00000000 fd:00 3270464
/usr/lib/locale/locale-archive
b7fcf000-b7fd1000 rw-p b7fcf000 00:00 0
b7fd8000-b7fd9000 rw-p b7fd8000 00:00 0
bf87f000-bf895000 rw-p bf87f000 00:00 0 [stack]
uid=2472829(prk2) gid=100001(PosixUsers)
groups=100001(PosixUsers),102744([redacted]),113787Aborted
The group is relatively large, looking at it in JXplorer just shows
members 0-1499, but we have other larger groups that don't cause the
problem. I'd appreciate any input or assistance anyone can offer. My
next step is to compile nss_ldap myself with debugging symbols to try to
get a better backtrace. Looking up this kind of error leads me to
believe that what may be happening is a write past the end of a buffer
stomping on glibc memory housekeeping records.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic