Re: Crash on recursive rebind following referral (ITS#3359)

[Kurt@OpenLDAP.org]

At 12:25 PM 10/5/2004, ipuleston@sonicwall.com wrote:
>Full_Name: Ian Puleston
>Version: 2.2.13

Please upgrade to 2.2.17 and retest.  If it crashes again,
please provide a stack back trace from a non-stripped
executable.  Thanks, Kurt

>OS: vxWorks
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (64.220.173.243)
>
>
>I have a setup with two OpenLDAP servers with referrals enabled and each
>configurred to refer to the other. This problem occurs if the DN for login is
>mis-configured so that it is in an ou that is valid on neither. A search
>operation results in an assert failure in function ldap_parse_result() due to
>the LDAPMessage *r parameter being NULL:
>
>assert failed: r != (0), file
>../../../../firmware/libsrc/openldap/libraries/libldap/error.c, line 277
>
>What is actually going on is that a bind attempt is made to the primary server,
>and it returns a referral. My ldo_rebind_proc function is then called, and it
>calls ldap_bind_s() to bind to the 2nd server. However, that server too returns
>a referral which results in a recursive call back to my ldo_rebind_proc function
>which again calls ldap_bind_s(). The assert failure occurs during that recursive
>call back to ldap_bind_s().
>
>ldap_new_connection -> ldo_rebind_proc -> ldap_bind_s -> ... -> ldo_rebind_proc
>-> ldap_bind_s -> assert failure!
>
>The stack trace is as follows (ldapReBind is my ldo_rebind_proc function) :
>
>ldap_do_search +7e9: 7e6d90 (697fd40, dd98add, 2, 0, 7e5f7c, 0, 0, 0, 0, 0,
>ffffffff)
>ldap_do_search +cf8: ldap_result (697fd40, ffffffff, 0, 0, 8f9a834)
>ldap_result    +f9 : 7eba00 ([697fd40, ffffffff, 0, 0, 8f9a834])
>ldap_result    +7b1: 7ec110 (697fd40, ffffffff, 0, 697f210, 8f9a7b0, 8f9a834)
>ldap_result    +1116: ldap_chase_v3referrals (697fd40, 697f448, 697f5c4, 0,
>697f464, 8f9a70c)
>ldap_chase_v3referrals+380: ldap_send_server_request (697fd40, 697f544, 3,
>697f448, 697f744, 0, 8f9a6a8)
>ldap_send_server_request+98 : ldap_new_connection (697fd40, 697f744, 0, 1,
>8f9a6a8)
>ldap_new_connection+176: ldapReBind (697fd40, 697f3c8, 63, 2, 0)
>ldapReBind     +305: ldap_bind_s (697fd40, ddfe9f0, &gLdapBindPwd, 80)
>ldap_bind_s    +53 : ldap_simple_bind_s ([697fd40, ddfe9f0, &gLdapBindPwd,
>697e310, 1a])
>ldap_simple_bind_s+6c : ldap_sasl_bind_s ([697fd40, ddfe9f0, 0, 8f9a5a4, 0])
>ldap_sasl_bind_s+9b : ldap_result (697fd40, 4, 1, 0, 8f9a56c)
>ldap_result    +f9 : 7eba00 ([697fd40, 4, 1, 0, 8f9a56c])
>ldap_result    +7b1: 7ec110 (697fd40, 4, 1, 697f6cc, 8f9a50c, 8f9a56c)
>ldap_result    +1116: ldap_chase_v3referrals (697fd40, 697e30c, 68e01a0, 0,
>697e328, 8f9a468)
>ldap_chase_v3referrals+380: ldap_send_server_request (697fd40, 697fc68, 5,
>697e30c, 697fb38, 0, 8f9a404)
>ldap_send_server_request+98 : ldap_new_connection (697fd40, 697fb38, 0, 1,
>8f9a404)
>ldap_new_connection+176: ldapReBind (697fd40, 68dfb14, 60, 4, 0)
>ldapReBind     +305: ldap_bind_s (697fd40, ddfe4a0, &gLdapBindPwd, 80)
>ldap_bind_s    +53 : ldap_simple_bind_s ([697fd40, ddfe4a0, &gLdapBindPwd,
>697a2de, 1a])
>ldap_simple_bind_s+6c : ldap_sasl_bind_s ([697fd40, ddfe4a0, 0, 8f9a300, 0])
>ldap_sasl_bind_s+f7 : ldap_result2error (697fd40, 0, 1)
>ldap_result2error+1e : ldap_parse_result ([697fd40, 0, 8f9a2a0, 0, 0])
>ldap_parse_result+140: taskSuspend (0)
>task tLdapTask was suspended at 0xbda396
>
>Since in my case this is caused by a configuration error, there is a simple
>workaround which is to have my  ldo_rebind_proc function return an LDAP_REFERRAL
>error in the case of a recursive call.