[Date Prev][Date Next] [Chronological] [Thread] [Top]

openldap library crash


First of all, I'd like to thank your effort on making this free software, which
has benefited us a lot in our product, an industry leading SSL VPN product.

Recently our customers(at least 2) started to complain user authentication
failure through ldap with recursive referral settings. The problem does not
happen everytime, but can be reproduced with reasonable number of re-try's(<20).

We are using openldap 2.1.22 in our product. We tried the latest download
but it doesn't fix the problem either. We only use the openldap library in
the authentication side as an ldap client, authenticate against Active

Because the ldapsearch command provided by openldap does not support
non-anonymous rebinding in referral chasing, I am not able to provide an
stack trace output from that command. Here is what we have:

------                                        --------
??:0                                          ??
??:0                                          ldap_result
??:0                                          ldap_sasl_bind
??:0                                          ldap_sasl_interactive_bind_s
install/include/dsutil/str.h:595              DSLdapServer::connect(DSStatus *)
install/include/dsutil/str.h:595              DSLdapServer::connect(DSStatus *)
??:0                                          ldap_new_connection
??:0                                          ldap_send_server_request
??:0                                          ldap_chase_v3referrals
??:0                                          try_read1msg
??:0                                          wait4msg
??:0                                          ldap_result

It shows the code entered referral chasing, and then rebind proc provided by
us, and then ldap_sasl_bind. Our debugging shows the code actually crashes in
libraries/libldap/result.c at

                   while (rc == -2) {
                                    for ( lc = ld->ld_conns; rc == -2
&& lc != NULL;
                                        lc = nextlc ) {
                                            nextlc = lc->lconn_next;
                                            if ( lc->lconn_status ==
                                                LDAP_CONNST_CONNECTED &&
                                                ldap_is_read_ready( ld,
                                                lc->lconn_sb )) {
                                                    rc = try_read1msg(
ld, msgid, all,
lc, result );

In the for loop, the 'nextlc' in some cases is not NULL but invalid.
It either causes
an assertion in ldap_is_read_ready() or SEGV in access to its pointer. Further
debugging shows in the case of assertion failure or SEGV crash, the address of
'nextlc' (assigned to 'lc' the next round) is freed in
ldap_free_connection() before
it reaches this loop. Not clear yet why ld->ld_conns still points to
that address which
has already been freed earlier.  Would it be possible that some other
variables also
hold that value and resets it back(to ld_conns) after it is freed ?

Saw some code changes in 2.3.19 release in this area but obviously it
doesn't fix this

It would be greatly appreciated if you could provide us some clue &
help on this issue.
Our QA also has verified, by using a java based ldap open source
library, the same
authentication problem does not occur.