Description of problem: Programs calling getpwuid() and/or getpwuid_r() may abort with the following (file paths shortened and arguments remove to improve readability; also some information is missing due to the static linking of openldap in nss_ldap): #0 0x00000031fda2e21d in raise () from [...]/libc.so.6 #1 0x00000031fda2fa1e in abort () from [...]/libc.so.6 #2 0x00000031fda27ae1 in __assert_fail () from /libc.so.6 #3 0x0000002a95b4797d in ber_sockbuf_ctrl () from [...]/libnss_ldap.so.2 #4 0x0000002a95b260d4 in try_read1msg () from [...]/libnss_ldap.so.2 #5 0x0000002a95b271b7 in ldap_result () from [...]/libnss_ldap.so.2 #6 0x0000002a95b28236 in ldap_search_st () from [...]/libnss_ldap.so.2 #7 0x0000002a95b1ddf0 in do_search_s () at ldap-nss.c:2257 #8 0x0000002a95b1dc16 in do_with_reconnect () at ldap-nss.c:2153 #9 0x0000002a95b1e180 in _nss_ldap_search_s () at ldap-nss.c:2635 #10 0x0000002a95b1e677 in _nss_ldap_getbyname () at ldap-nss.c:2970 #11 0x0000002a95b1f700 in _nss_ldap_getpwuid_r () at ldap-pwd.c:202 #12 0x00000031fda8ea2d in getpwuid_r@@GLIBC_2.2.5 () from [...]/libc.so.6 #13 0x000000000040baf2 in get_user_info_old () #14 0x000000000040d7f6 in process_exec_msg () #15 0x000000000041aaa6 in main_exec () #16 0x000000000040477d in handle_connect_request () #17 0x00000031fe50610a in start_thread () from [...]/libpthread.so.0 #18 0x00000031fdac68c3 in clone () from [...]/libc.so.6 #19 0x0000000000000000 in ?? () Analysis from the partner shows that the failed assertion is from line 91 of libraries/liblber/sockbuf.c: 84 int 85 ber_sockbuf_ctrl( Sockbuf *sb, int opt, void *arg ) 86 { 87 Sockbuf_IO_Desc *p; 88 int ret = 0; 89 90 assert( sb != NULL ); 91 assert( SOCKBUF_VALID( sb ) ); ber_sockbuf_ctrl() is called in try_read1msg() after possibly calling ldap_free_connection() in libraries/libldap/result.c: 410 static ber_tag_t 411 try_read1msg( 412 LDAP *ld, 413 ber_int_t msgid, 414 int all, 415 Sockbuf *sb, 416 LDAPConn **lcp, 417 LDAPMessage **result ) 418 { 419 BerElement *ber; 420 LDAPMessage *new, *l, *prev, *tmp; 421 ber_int_t id; 422 ber_tag_t tag; 423 ber_len_t len; 424 int foundit = 0; 425 LDAPRequest *lr, *tmplr; 426 LDAPConn *lc; : 449 lc = *lcp; : 824 if ( lc != NULL ) { 825 ldap_free_connection( ld, lc, 0, 1 ); 826 *lcp = NULL; 827 } : 990 exit: 991 if ( foundit ) { 992 ld->ld_errno = LDAP_SUCCESS; 993 return( tag ); 994 } 995 if ( ber_sockbuf_ctrl( sb, LBER_SB_OPT_DATA_READY, NULL ) ) { This is nearly identical to a problem described in Bug 474788 and resolved upstream: http://www.openldap.org/its/index.cgi/Software Bugs?id=5853 Based on this analysis and information, the partner would like us to rebuild nss_ldap to incorporate the changes in openldap-2.2.13-12.el4_8.2. Version-Release number of selected component (if applicable): nss_ldap-253-5.el4 How reproducible: Not very Actual results: Program aborts. Expected results: Program doesn't abort.
We received a customer report that the 'su' or 'id' commands would abort when an LDAP username was used as a parameter. The error message was: su: ../../../libraries/liblber/sockbuf.c:91: ber_sockbuf_ctrl: Assertion `( (sb) ->sb_opts.lbo_valid == 0x3 )' failed. Reproduction of the problem using a dynamically-linked nss_ldap built by jnansi resulted in the following backtrace: #0 0x000000397bc2e26d in *__GI_raise (sig=Variable "sig" is not available.) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #1 0x000000397bc2fa6e in *__GI_abort () at ../sysdeps/generic/abort.c:88 #2 0x000000397bc27af1 in *__GI___assert_fail (assertion=Variable "assertion" is not available. ) at assert.c:83 #3 0x00000030b7a0a2fd in ber_sockbuf_ctrl (sb=0x5b4280, opt=Variable "opt" is not available. ) at ../../../libraries/liblber/sockbuf.c:91 #4 0x00000030b780d26c in try_read1msg (ld=0x50e350, msgid=47, all=0, sb=0x5b4280, lcp=0x7fbfffe358, result=0x50f6a8) at ../../../libraries/libldap/result.c:995 #5 0x00000030b780da07 in ldap_result (ld=0x50e350, msgid=47, all=0, timeout=Variable "timeout" is not available. ) at ../../../libraries/libldap/result.c:378 #6 0x0000002a984d2c3c in do_result (ctx=0x50f690, all=0) at ldap-nss.c:2408 #7 0x0000002a984d3913 in do_parse (ctx=0x50f690, result=0x7fbffff780, buffer=0x0, buflen=0, errnop=0x7fbfffed44, parser=0x2a984d6590 <do_parse_initgroups_nested>) at ldap-nss.c:2793 #8 0x0000002a984d40d9 in _nss_ldap_getent_ex (args=0x7fbfffed60, ctx=0x7fbfffed48, result=0x7fbffff780, buffer=0x0, buflen=0, errnop=0x7fbfffed44, filterprot=0x2a985ea880 "(&(objectClass=Group)(uniqueMember=%s))", sel=LM_GROUP, user_attrs=0x7fbfffed90, parser=0x2a984d6590 <do_parse_initgroups_nested>) at ldap-nss.c:3366 #9 0x0000002a984d697e in do_parse_initgroups_nested (e=0x50f520, pvt=Variable "pvt" is not available. ) at ldap-grp.c:865 #10 0x0000002a984d38d3 in do_parse (ctx=0x50f480, result=0x7fbffff780, buffer=0x0, buflen=0, errnop=0x2a9556ada0, parser=0x2a984d6590 <do_parse_initgroups_nested>) at ldap-nss.c:2812 #11 0x0000002a984d40d9 in _nss_ldap_getent_ex (args=0x7fbffff750, ctx=0x7fbffff720, result=0x7fbffff780, buffer=0x0, buflen=0, errnop=0x2a9556ada0, filterprot=0x2a985e8480 "(&(objectClass=Group)(|(memberUid=%s)(uniqueMember=%s)))", sel=LM_GROUP, user_attrs=0x7fbffff730, parser=0x2a984d6590 <do_parse_initgroups_nested>) at ldap-nss.c:3366 #12 0x0000002a984d6c65 in _nss_ldap_initgroups_dyn (user=Variable "user" is not available.) at ldap-grp.c:1133 #13 0x000000397bc8d845 in internal_getgrouplist (user=0x7fbffffbf2 "<redacted>",group=10004, size=0x7fbffff878, groupsp=0x7fbffff880, limit=-1) at initgroups.c:99 #14 0x000000397bc8d9ee in getgrouplist (user=0x7fbffffbf2 "<redacted>", group=10004, groups=0x0, ngroups=0x7fbffff8b4) at initgroups.c:153 #15 0x00000000004016fa in xgetgroups ( username=0x312b <Address 0x312b out of bounds>, gid=<redacted>, n_groups=0x7fbffff8fc, groups=0x7fbffff900) at id.c:322 #16 0x0000000000401d22 in main (argc=Variable "argc" is not available.) at id.c:456 #17 0x000000397bc1c40b in __libc_start_main (main=0x4017f0 <main>, argc=2, ubp_av=0x7fbffffa18, init=0x4032d0 <__libc_csu_init>, fini=Variable "fini" is not available. ) at ../sysdeps/generic/libc-start.c:209 #18 0x000000000040149a in _start () #19 0x0000007fbffffa08 in ?? () #20 0x000000000000001c in ?? () #21 0x0000000000000002 in ?? () #22 0x0000007fbffffbef in ?? () #23 0x0000007fbffffbf2 in ?? () #24 0x0000000000000000 in ?? () which is very similar to the backtrace described in this Bug. In addition, the problem was non-reproducible with a version of nss_ldap that was linked with openldap-2.2.13-12.el4_8.2. This tends to validate the analysis performed by Red Hat's partner in Comment #0.
*** Bug 318531 has been marked as a duplicate of this bug. ***
Event posted on 2009-10-09 11:32 EDT by jwilleford I believe this issue is still awaiting ack(s). What is the eta on the errata for this? This event sent from IssueTracker by jwilleford issue 337078
@GSS, @jwilleford, @Bryan It appears the reproducibility of this issue is low. We need to confirm that there is commitment from the reporter to test for the resolution of this request if it is accepted into the release. Please post a confirmation as soon as possible, including the contact information for testing engineers.
(In reply to comment #10) > @GSS, @jwilleford, @Bryan > > It appears the reproducibility of this issue is low. Actually, reproducibility of the issue is 100% in the customer environment when the 'id' or 'su' commands are given with a parameter that is a user whose information (uid, gid, etc.) resides on an Active Directory server. When this same customer attempted to reproduce the problem with a test version of nss_ldap that was linked with openldap-2.2.13-12.el4_8.2, the problem was not reproducible. The test version of nss_ldap was based on nss_ldap-253-7.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The nss_ldap module is built with a static copy of the libldap library. Applications which called the getpwuid() or getpwuid_r() functions could have triggered an assertion failure in libldap, thus causing the nss_ldap module to terminate abnormally. This fix updates the static copy of libldap built into nss_ldap, and potential assertion failures are no longer triggered.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0239.html