(ITS#8718) Connection delete callback registreed with LDAP_OPT_CONNECT_CB is not called on TLS failure

[ipuleston@sonicwall.com]

Full_Name: Ian Puleston
Version: 2.4.40
OS: VxWorks
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (204.118.31.9)


If connect and delete callbacks are registered via LDAP_OPT_CONNECT_CB, then the
lc_add callback is called when the TCP connects, but if TLS then fails to
connect the lc_del does not get called. If these callbacks are doing something
like allocating/freeing resources this can lead to a resource leak.

When I am seeing this, the sequence of calls leading to the lc_add callback is
as follows:

ldap_new_connection -> ldap_int_open_connection -> ldap_connect_to_host ->
ldap_int_connect_cbs()

Then if ldap_connect_to_host returned 0 for synchronous success this call
happens:

ldap_new_connection -> ldap_int_open_connection -> ldap_int_tls_start

And if that fails and returns something other than LDAP_SUCCESS then
ldap_int_open_connection exits. So we got a call to lc_add but no corresponding
call to lc_del.

And note that there is not call to ldap_free_connection, presumably because
ldap-new-connection did not succeed, hence the lc_del callback does not get
called from there.

In my case when I see this it is on a referral with the above calls made from
ldap_chase_v3referrals, hence it is happening synchronously. Whether the same
would happen with an asynchronous connect I don't know.

I do have a working fix which is to make the lc_del callbacks directly from
ldap_int_open_connection if ldap_int_tls_start fails. I will supply a patch for
that shortly.