[Bug]: wolfSSL_Cleanup does not free resources

[xXREDSTONEXx]

Contact Details

No response

Version

5.8.2 wolfssl, 3.22.0 valgrind, gcc 13.3.0

Description

WolfSSL's documentation says wolfSSL_Cleanup frees any resources used by the library however, this is not the case for example when making a new method i still need to make a context and free the method and calling wolfSSL_Cleanup does not free the memory allocated by the method.

Reproduction steps

compile and run this code
gcc leaktest.c -lwolfssl; valgrind --leak-check=full ./a.out

#include <arpa/inet.h>
#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
#include <wolfssl/test.h>
#define SERV_PORT 11111

int main()
{
    int sockfd;
    WOLFSSL_CTX* ctx;
    WOLFSSL* ssl;
    WOLFSSL_METHOD* method;
    struct  sockaddr_in servAddr;
    const char message[] = "Hello, World!";

    /* create and set up socket */
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    memset(&servAddr, 0, sizeof(servAddr));
    servAddr.sin_family = AF_INET;
    servAddr.sin_port = htons(SERV_PORT);
    /* initialize wolfssl library */
    wolfSSL_Init();
    method = wolfTLSv1_2_client_method(); /* use TLS v1.2 */
    //wolfSSL_CTX_free(wolfSSL_CTX_new(method));
    wolfSSL_Cleanup();
}

expected:
all memory was freed and valgrind detected no leaks
actual result:
memory was not freed (see log output)

Relevant log output

==2611294== Memcheck, a memory error detector
==2611294== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2611294== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==2611294== Command: ./a.out
==2611294== 
==2611294== 
==2611294== HEAP SUMMARY:
==2611294==     in use at exit: 4 bytes in 1 blocks
==2611294==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==2611294== 
==2611294== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2611294==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==2611294==    by 0x48EC40E: wolfTLSv1_2_client_method_ex (in /usr/local/lib/libwolfssl.so.44.0.0)
==2611294==    by 0x109341: main (in ~/a.out)
==2611294== 
==2611294== LEAK SUMMARY:
==2611294==    definitely lost: 4 bytes in 1 blocks
==2611294==    indirectly lost: 0 bytes in 0 blocks
==2611294==      possibly lost: 0 bytes in 0 blocks
==2611294==    still reachable: 0 bytes in 0 blocks
==2611294==         suppressed: 0 bytes in 0 blocks
==2611294== 
==2611294== For lists of detected and suppressed errors, rerun with: -s
==2611294== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


note: the following is with line 23 uncommented
==2613312== Memcheck, a memory error detector
==2613312== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2613312== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==2613312== Command: ./a.out
==2613312== 
==2613312== 
==2613312== HEAP SUMMARY:
==2613312==     in use at exit: 0 bytes in 0 blocks
==2613312==   total heap usage: 3 allocs, 3 frees, 548 bytes allocated
==2613312== 
==2613312== All heap blocks were freed -- no leaks are possible
==2613312== 
==2613312== For lists of detected and suppressed errors, rerun with: -s
==2613312== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[kareem-wolfssl]

Hi @xXREDSTONEXx,

Thanks for the report. wolfSSL_Cleanup is responsible for freeing/cleaning up global resources allocated by wolfSSL_Init. The method allocated by wolfTLSv1_2_client_method is independent of this, and is not expected to be free'd. You should either create a WOLFSSL_CTX based on this method and free it (as you are in the line wolfSSL_CTX_free(wolfSSL_CTX_new(method));) or remove the call to allocate the method. With either of these changes, I see no memory leaking.

[xXREDSTONEXx]

If you can't create a context to free the method (wolfSSL_CTX_new failed) what would be the right course of action? In the example tls client given by wolfssl cleanup is called upon failure to create a context but cleanup doesn't free the method, I believe you could free the method directly if ctx was failed to be created but if this is the right course of action I believe the example client should have this

[kareem-wolfssl]

wolfSSL_CTX_New handles this, if there's a failure setting up the ctx, the WOLFSSL_METHOD passed in is freed as part of the cleanup:

/* Create a new WOLFSSL_CTX struct and return the pointer to created struct.
   WOLFSSL_METHOD pointer passed in is given to ctx to manage.
   This function frees the passed in WOLFSSL_METHOD struct on failure and on
   success is freed when ctx is freed.
 */

The correct thing to do is to always pass in the WOLFSSL_METHOD to wolfSSL_CTX_New, and to call wolfSSL_CTX_free on cleanup.

I'm closing this, feel free to reopen if you have further questions or issues.

[xXREDSTONEXx]

Where did you find that documentation?
https://www.wolfssl.com/documentation/manuals/wolfssl/group__Setup.html#function-wolfssl_ctx_new

[kareem-wolfssl]

That documentation comes from inside of the code itself, see src/ssl.c around wolfSSL_CTX_new_ex: https://github.com/wolfSSL/wolfssl/blob/master/src/ssl.c#L1139

[xXREDSTONEXx]

Could this documentation be included on the site as well?