BIO_do_connect memory leak in Arch Linux

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

BIO_do_connect memory leak in Arch Linux

Ryan Beethe
Hi openssl-users,

I found a memory leak in my program that arises from the use of the
BIO_do_connect() function.  It seems to be related to how openssl is
interacting with other packages on my system.  I observe this behavior
on my Arch Linux machine but not on my Debian Stretch machine.  I wrote
a minimal program that demonstrates the issue and attached the output of
valgrind of the same program.

The leak goes away if I comment out the BIO_do_connect() line, and based
on the output of valgrind the issue seems to have something to do with
the DNS resolving step.  I noticed using strace that on Arch Linux the
same binary running on Arch Linux loads two libraries that don't get
loaded when running on Debian Stretch: "libnss_mymachines.so.2" and
"libnss_resolve.so.2".

Am I doing something wrong or is this a memory leak in openssl?

Thanks,

Ryan


------- leak.c: a minimal example program leak.c

// # compile with gcc 7.2.1:
// gcc -Wall -g -std=c99 -pedantic leak.c -lssl -lcrypto -o leak

#include <stdio.h>
#include <openssl/bio.h>

int main(){
    // unencrypted connection
    BIO* bio = BIO_new_connect("smtp.gmail.com:587");

    // connect BIO
    BIO_do_connect(bio);

    // read some stuff
    char buffer[1024];
    int ret = BIO_read(bio, buffer, 1024 - 1);
    printf("read %d bytes:\n",ret);
    fwrite(buffer, 1, ret, stdout);

    BIO_free_all(bio);

    printf("exiting\n");
    return 0;
}


---------- output of: valgrind --show-leak-kinds=all --leak-check=full ./leak

==6700== Memcheck, a memory error detector
==6700== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6700== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6700== Command: ./leak
==6700==
read 52 bytes:
220 smtp.gmail.com ESMTP d26sm175472lja.54 - gsmtp
exiting
==6700==
==6700== HEAP SUMMARY:
==6700==     in use at exit: 7,365 bytes in 10 blocks
==6700==   total heap usage: 148 allocs, 138 frees, 118,960 bytes allocated
==6700==
==6700== 48 bytes in 1 blocks are still reachable in loss record 1 of 6
==6700==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==    by 0x4011D85: tls_get_addr_tail (in /usr/lib/ld-2.26.so)
==6700==    by 0x4017447: __tls_get_addr (in /usr/lib/ld-2.26.so)
==6700==    by 0x65BBD1D: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x65D7711: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x65CE60C: _nss_resolve_gethostbyname4_r (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x566DFD8: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so)
==6700==    by 0x566EF03: getaddrinfo (in /usr/lib/libc-2.26.so)
==6700==    by 0x517160D: BIO_lookup_ex (b_addr.c:691)
==6700==    by 0x51716CD: BIO_lookup (b_addr.c:614)
==6700==    by 0x517C8BD: conn_state (bss_conn.c:123)
==6700==    by 0x517C8BD: conn_ctrl (bss_conn.c:360)
==6700==    by 0x5178F73: BIO_ctrl (bio_lib.c:529)
==6700==
==6700== 61 bytes in 2 blocks are still reachable in loss record 2 of 6
==6700==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==    by 0x401AB9A: strdup (in /usr/lib/ld-2.26.so)
==6700==    by 0x40162EF: _dl_load_cache_lookup (in /usr/lib/ld-2.26.so)
==6700==    by 0x40089D1: _dl_map_object (in /usr/lib/ld-2.26.so)
==6700==    by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==    by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==
==6700== 61 bytes in 2 blocks are still reachable in loss record 3 of 6
==6700==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==    by 0x400B468: _dl_new_object (in /usr/lib/ld-2.26.so)
==6700==    by 0x4005984: _dl_map_object_from_fd (in /usr/lib/ld-2.26.so)
==6700==    by 0x40086B0: _dl_map_object (in /usr/lib/ld-2.26.so)
==6700==    by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==    by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==
==6700== 720 bytes in 2 blocks are still reachable in loss record 4 of 6
==6700==    at 0x4C2EEF5: calloc (vg_replace_malloc.c:711)
==6700==    by 0x4010F03: _dl_check_map_versions (in /usr/lib/ld-2.26.so)
==6700==    by 0x4013822: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==    by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==    by 0x56A71E8: __nss_lookup_function (in /usr/lib/libc-2.26.so)
==6700==    by 0x566DF76: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so)
==6700==
==6700== 2,379 bytes in 2 blocks are still reachable in loss record 5 of 6
==6700==    at 0x4C2EEF5: calloc (vg_replace_malloc.c:711)
==6700==    by 0x400B181: _dl_new_object (in /usr/lib/ld-2.26.so)
==6700==    by 0x4005984: _dl_map_object_from_fd (in /usr/lib/ld-2.26.so)
==6700==    by 0x40086B0: _dl_map_object (in /usr/lib/ld-2.26.so)
==6700==    by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so)
==6700==    by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so)
==6700==    by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so)
==6700==    by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so)
==6700==
==6700== 4,096 bytes in 1 blocks are still reachable in loss record 6 of 6
==6700==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==6700==    by 0x65BBF48: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x65D7711: ??? (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x65CE60C: _nss_resolve_gethostbyname4_r (in /usr/lib/libnss_resolve.so.2)
==6700==    by 0x566DFD8: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so)
==6700==    by 0x566EF03: getaddrinfo (in /usr/lib/libc-2.26.so)
==6700==    by 0x517160D: BIO_lookup_ex (b_addr.c:691)
==6700==    by 0x51716CD: BIO_lookup (b_addr.c:614)
==6700==    by 0x517C8BD: conn_state (bss_conn.c:123)
==6700==    by 0x517C8BD: conn_ctrl (bss_conn.c:360)
==6700==    by 0x5178F73: BIO_ctrl (bio_lib.c:529)
==6700==    by 0x108954: main (leak.c:17)
==6700==
==6700== LEAK SUMMARY:
==6700==    definitely lost: 0 bytes in 0 blocks
==6700==    indirectly lost: 0 bytes in 0 blocks
==6700==      possibly lost: 0 bytes in 0 blocks
==6700==    still reachable: 7,365 bytes in 10 blocks
==6700==         suppressed: 0 bytes in 0 blocks
==6700==
==6700== For counts of detected and suppressed errors, rerun with: -v
==6700== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: BIO_do_connect memory leak in Arch Linux

OpenSSL - User mailing list
It appears to be a memory leak in the DNS libraries.
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users