Openldap - Memory Leak - ldap_set_options - New context for Secure LDAP scenario (Cert Available)

Dear fellow developers,

We are facing a leak in ldap_set_option -

While doing - ldap_rc = ldap_set_option(*ldp, LDAP_OPT_X_TLS_NEWCTX, &tls_option);

while in openldap code a memory allocation of -
BIO_meth_new( int type, const char *name )
{
BIO_METHOD *method = LDAP_MALLOC( sizeof(BIO_METHOD) );
memset( method, 0, sizeof(BIO_METHOD) );

    method->type = type;
    method->name = name;

    return method;

}

The BIO method which is a global context allocated dynamically in LDAP_MALLOC is not gettibg frred, resulting a 48 b byte increase in valgrind leak analysis -

==2427== 61 (48 direct, 13 indirect) bytes in 1 blocks are definitely lost in loss record 494 of 1,015
==2427== at 0x4848EE4: malloc (vg_replace_malloc.c:393)
==2427== by 0x4A71BA7: CRYPTO_zalloc (mem.c:230)
==2427== by 0x49B677F: BIO_meth_new (bio_meth.c:38)
==2427== by 0xA1CB7AB: tlso_bio_setup (tls_o.c:1311)
==2427== by 0xA1CB7AB: tlso_init (tls_o.c:234)
==2427== by 0xA1C7577: ldap_int_tls_init_ctx (tls2.c:211)
==2427== by 0xA1C8547: ldap_pvt_tls_set_option (tls2.c:991)
==2427== by 0xA1BD617: ldap_set_option (options.c:860)
==2427== by 0xA0BACCB: _init_bmc_ldap (pam_bmc_ldap.c:1318)
==2427== by 0xA0BDD37: ldap_auth (pam_bmc_ldap.c:1920)
==2427== by 0xA0B3BA3: pam_sm_authenticate (pam_bmc.c:1255)
==2427== by 0x4E776DF: _pam_dispatch_aux (pam_dispatch.c:110)
==2427== by 0x4E776DF: _pam_dispatch (pam_dispatch.c:426)
==2427== by 0x4E77063: pam_authenticate (pam_auth.c:34)
==2427== by 0x4E618FB: redfish_pam_authenticate (redfish_pam_handler.c:250)
==2427== by 0x4E5FF3F: redfish_data_pam_login (redfish_data_handler.c:154)
==2427== by 0x4E60C9F: redfish_do_basic_auth (redfish_data_handler.c:570)
==2427== by 0xF338F: verify_authentication (oem_authentication.c:182)
==2427== by 0x1AE2B: request_process (request.c:1616)
==2427== by 0xF0EEB: fcgi_worker_thread (fcgi.c:553)
==2427== by 0x517736B: start_thread (pthread_create.c:486)
==2427== by 0x52A9B57: ??? (clone.S:73)

We tried to prevent it by calling - ldap_pvt_tls_destroy() after each ldap_unbind_ext_s(*ldp, NULL, NULL)

But in scenarios where simultaneously ldap_initialize() is called from global context freeing by ldap_pvt_tls_destroy() causing core.

If there is any getway with this scenario, please let us know.

Quick responses are highly appreciated.

Regards,
Pankaj Ghosh

Start by tracing the reported call path through tls_o.c, tls2.c, and options.c, then inspect the callers in pam_bmc_ldap.c. Reproduce the secure LDAP scenario under Valgrind and compare repeated ldap_initialize(), ldap_set_option(), and unbind cycles. Done means the leak is accounted for or eliminated without causing the reported crash.