(ITS#4448) libldap referral chasing issue under load

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: HEAD,re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


I'm experiencing issues in (concurrently?) chasing referrals under load via
libldap.  There are few outstanding ITSes about referral chasing in libldap:

ITS#4405 seems to be related to rebinding
ITS#3526 about using the correct identity for further referral chasing with
slapo-chain
ITS#4070 about the opportunity of chasing referrals from within the proxy
backends instead of via libldap

Now I've found some severe issue in referral chasing code.  I'm about to commit
a regression test for this issue that reproduces it very easily.  valgrind
shows:

==30061== Thread 8:
==30061== Invalid read of size 2
==30061==    at 0x60ABE4: ber_sockbuf_ctrl (sockbuf.c:89)
==30061==    by 0x5DAB00: try_read1msg (result.c:968)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)
==30061==    by 0x44E828: do_add (add.c:182)
==30061==    by 0x4461F6: connection_operation (connection.c:1339)
==30061==    by 0x4466F1: connection_read_thread (connection.c:1466)
==30061==    by 0x5D73C8: ldap_int_thread_pool_wrapper (tpool.c:614)
==30061==  Address 0x1399D4C8 is 0 bytes inside a block of size 32 free'd
==30061==    at 0x11B1AA2D: free (vg_replace_malloc.c:235)
==30061==    by 0x6096F6: ber_memfree_x (memory.c:149)
==30061==    by 0x609750: ber_memfree (memory.c:162)
==30061==    by 0x60ABA0: ber_sockbuf_free (sockbuf.c:76)
==30061==    by 0x5EF27B: ldap_free_connection (request.c:579)
==30061==    by 0x5DA897: try_read1msg (result.c:803)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)

==30061== Invalid read of size 8
==30061==    at 0x60AD99: ber_sockbuf_ctrl (sockbuf.c:154)
==30061==    by 0x5DAB00: try_read1msg (result.c:968)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)
==30061==    by 0x44E828: do_add (add.c:182)
==30061==    by 0x4461F6: connection_operation (connection.c:1339)
==30061==    by 0x4466F1: connection_read_thread (connection.c:1466)
==30061==    by 0x5D73C8: ldap_int_thread_pool_wrapper (tpool.c:614)
==30061==  Address 0x1399D4D0 is 8 bytes inside a block of size 32 free'd
==30061==    at 0x11B1AA2D: free (vg_replace_malloc.c:235)
==30061==    by 0x6096F6: ber_memfree_x (memory.c:149)

==30061== Invalid read of size 8
==30061==    at 0x60AD9D: ber_sockbuf_ctrl (sockbuf.c:154)
==30061==    by 0x5DAB00: try_read1msg (result.c:968)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)
==30061==    by 0x44E828: do_add (add.c:182)
==30061==    by 0x4461F6: connection_operation (connection.c:1339)
==30061==    by 0x4466F1: connection_read_thread (connection.c:1466)
==30061==    by 0x5D73C8: ldap_int_thread_pool_wrapper (tpool.c:614)
==30061==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==30061==
==30061== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==30061==  Access not within mapped region at address 0x10
==30061==    at 0x60AD9D: ber_sockbuf_ctrl (sockbuf.c:154)
==30061==    by 0x5DAB00: try_read1msg (result.c:968)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)
==30061==    by 0x44E828: do_add (add.c:182)
==30061==    by 0x4461F6: connection_operation (connection.c:1339)
==30061==    by 0x4466F1: connection_read_thread (connection.c:1466)
==30061==    by 0x5D73C8: ldap_int_thread_pool_wrapper (tpool.c:614)

==30061==    by 0x609750: ber_memfree (memory.c:162)
==30061==    by 0x60ABA0: ber_sockbuf_free (sockbuf.c:76)
==30061==    by 0x5EF27B: ldap_free_connection (request.c:579)
==30061==    by 0x5DA897: try_read1msg (result.c:803)
==30061==    by 0x5D9921: wait4msg (result.c:347)
==30061==    by 0x5D9177: ldap_result (result.c:124)
==30061==    by 0x5534B3: meta_back_add (add.c:190)
==30061==    by 0x44EE40: fe_op_add (add.c:331)

The code over there looks quite weird.  It seems that in case of abnormal
conditions, resources passed by value (pointers) are freed, so that the callers
keep dangling pointers around.  I'm investigating further.  I can provide core
dumps in case; the tests will be committed shortly in tests/data/regressions/
with this ITS' number.

p.