lists.arthurdejong.org
RSS feed

[nssldap] nss_ldap crash in CentOS 5

[Date Prev][Date Next] [Thread Prev][Thread Next]

[nssldap] nss_ldap crash in CentOS 5



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.