memory leak debug options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux