Hello,
Currently we are seeing below 3 patterns of memory leak issue with Openssl
1.1.1i and 1.1.1k version using address santizer option as below:
Direct leak of 208 byte(s) in 2 object(s) allocated from:
#0 0x9ef57b in __interceptor_malloc
(/usr/local/bin/autoai/custom_binary+0x9ef57b)
#1 0xffffac627743 in BN_MONT_CTX_new (/usr/lib64/libcrypto.so.1.1+0xaf743)
#2 0xffffac627baf in BN_MONT_CTX_set_locked
(/usr/lib64/libcrypto.so.1.1+0xafbaf)
#3 0xffffac6ec77b (/usr/lib64/libcrypto.so.1.1+0x17477b)
rsa_ossl_public_decrypt
#4 0xffffac6f0577 (/usr/lib64/libcrypto.so.1.1+0x178577)
RSA_verify_ASN1_OCTET_STRING
#5 0xffffac6eef1b (/usr/lib64/libcrypto.so.1.1+0x176f1b) pkey_rsa_verify
#6 0xffffac6b44cf in EVP_DigestVerifyFinal
(/usr/lib64/libcrypto.so.1.1+0x13c4cf)
#7 0xffffac8d95c7 (/usr/lib64/libssl.so.1.1+0x515c7)
tls_process_key_exchange ->EVP_DigestVerify->EVP_DigestVerifyFinal
#8 0xffffac8d9b33 (/usr/lib64/libssl.so.1.1+0x51b33)
ossl_statem_client_process_message
#9 0xffffac8d3acb (/usr/lib64/libssl.so.1.1+0x4bacb) state_machine ->
read_state_machine -> *process_change->ossl_statem_client_process_message
#10 0xffffac8c01fb in SSL_do_handshake (/usr/lib64/libssl.so.1.1+0x381fb)
via SSL_connect
#11 0xffffac858f3b (/usr/lib64/libcurl.so.4+0x4ff3b) ossl_connect_step2
#12 0xffffac85afeb (/usr/lib64/libcurl.so.4+0x51feb) ossl_connect_common
#13 0xffffac85c1ef (/usr/lib64/libcurl.so.4+0x531ef)
Curl_ssl_connect_nonblocking
#14 0xffffac82c96f (/usr/lib64/libcurl.so.4+0x2396f) https_connecting
Indirect leak of 2064 byte(s) in 2 object(s) allocated from:
#0 0x9ef57b in __interceptor_malloc
(/usr/local/bin/autoai/custom_binary+0x9ef57b)
#1 0xffffac6bf173 in CRYPTO_zalloc (/usr/lib64/libcrypto.so.1.1+0x147173)
#2 0xffffac625fd7 (/usr/lib64/libcrypto.so.1.1+0xadfd7)bn_expand2
#3 0xffffac6262af in BN_set_bit (/usr/lib64/libcrypto.so.1.1+0xae2af)
#4 0xffffac627a0b in BN_MONT_CTX_set (/usr/lib64/libcrypto.so.1.1+0xafa0b)
#5 0xffffac627bc3 in BN_MONT_CTX_set_locked
(/usr/lib64/libcrypto.so.1.1+0xafbc3)
<Curl backtrace is same as above>
Indirect leak of 1536 byte(s) in 5 object(s) allocated from:
#0 0x9ef57b in __interceptor_malloc
(/usr/local/bin/autoai/custom_binary+0x9ef57b)
#1 0xffffac6bf173 in CRYPTO_zalloc (/usr/lib64/libcrypto.so.1.1+0x147173)
#2 0xffffac625fd7 (/usr/lib64/libcrypto.so.1.1+0xadfd7) bn_expand2
#3 0xffffac626143 in BN_copy (/usr/lib64/libcrypto.so.1.1+0xae143)
#4 0xffffac6278a3 in BN_MONT_CTX_set (/usr/lib64/libcrypto.so.1.1+0xaf8a3)
#5 0xffffac627bc3 in BN_MONT_CTX_set_locked
(/usr/lib64/libcrypto.so.1.1+0xafbc3)
<Curl backtrace is same as above>
After statical analysis we noted that the crypto_malloc and crypto_free
functions are further called.
In these functions we could see debug flags OPENSSL_NO_CRYPTO_MDEBUG and
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE which might provide useful information in
debugging this leak issue.
In this regard we have below queries:-
1. Could you please let us know how to enable/check the logs generated by above
debug flags ?
2. We tried one experiment wherein we have disabled flags
RSA_FLAG_CACHE_PUBLIC, RSA_FLAG_CACHE_PRIVATE from rsa_ossl_init() function and
we can see that above leak does not happen.
In this regards, are there any known issue/fixes available which we could
try.
2. Any other suggesstion for debugging this memory leak from openssl point of
view, would be welcome.
Regards,
Chetan
