Re: [openssl-users] BIO_do_connect memory leak in Arch Linux

2018-02-04 Thread Salz, Rich via openssl-users
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


[openssl-users] BIO_do_connect memory leak in Arch Linux

2018-02-04 Thread 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 
#include 

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