memory still reachable post calling SSL_CTX_free

[Tomas Mraz]

On Tue, 2022-06-21 at 10:33 +0000, Tiwari, Hari Sahaya wrote:
> Hi,
> I need one clarification on routine SSL_CTX_free(). I see the memory
> is not freed even after calling this SSL_CTX_free().
>  
> I have a simple test program, which just does SSL_CTX_new() and 
> SSL_CTX_free().
>  
> #include<stdio.h>
> #include <openssl/ssl.h>
>  
> int main()
> {
>     const SSL_METHOD *method;
>     SSL_CTX *ctx = NULL;
>     OPENSSL_init_ssl(0, NULL);
>     method = TLS_method();
>     ctx = SSL_CTX_new(method);
>     if ( ctx == NULL ) {
>         return(-1);
>     }
>     SSL_CTX_free(ctx);
>     ctx=NULL;
>     sleep(300);

sleep() won't help you at all as there is no concurrent thread running
or anything else that would remove things for you when the process is
sleeping.

> }
>  
> If the program is terminated after it enters the sleep, I am seeing
> memory is still reachable in valgrind.
>  
> Here is output from valgrind,
>  
> ==443000== 10,224 bytes in 426 blocks are still reachable in loss
> record 593 of 594
> ==443000==    at 0x4C34F0B: malloc (vg_replace_malloc.c:307)
> ==443000==    by 0x525D775: OPENSSL_LH_insert (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x522DDB2: ??? (in /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x522E1CF: ERR_load_strings_const (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x4E79083: ERR_load_SSL_strings (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x4E790BC: ??? (in /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x5DABCD6: __pthread_once_slow (in
> /usr/lib64/libpthread-2.28.so)
> ==443000==    by 0x52C4ADC: CRYPTO_THREAD_run_once (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x4E794FA: OPENSSL_init_ssl (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x4E7D371: SSL_CTX_new (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x400749: main (in /home/hari/a.out)
> 

This is actually not a memory allocated by the SSL_CTX_new() itself but
error string data that is global. There is no real memory leak here.
You can call OPENSSL_cleanup() to explicitly de-allocate all the global
data however please note that you can do it really only before
immediate exit of the application using OpenSSL otherwise you risk
crashes if something tries to call OpenSSL again after
OPENSSL_cleanup() was called.

> SSL_CTX_free is already called before sleep(), but memory is still
> hanging around.
> Is there something I am missing here? Do I need to follow some other
> steps ?
> This memory leak is impacting our long term running processes, which
> allocate and free context.

This should not be the case as this memory should be allocated only
once. If you, in your test code, do SSL_CTX_new/SSL_CTX_free in a loop
you should still see just the same memory leaked and not more blocks.

-- 
Tomáš Mráz, OpenSSL