lib/44420: libfetch does not call SSL_free on SSL connections

[dan%archlinux.org@localhost]

>Number:         44420
>Category:       lib
>Synopsis:       libfetch does not call SSL_free on SSL connections
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 19 19:20:00 +0000 2011
>Originator:     Dan McGee
>Release:        N/A
>Organization:
Arch Linux
>Environment:
$ uname -a
Linux galway 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 
Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux


$ pacman -Q libfetch
libfetch 2.33-1
>Description:
When initializing an SSL connection using OpenSSL, SSL_new() is called. 
However, there is no matching call to SSL_free() during connection teardown.

$ sudo valgrind --suppressions=valgrind.supp --leak-check=full 
./src/pacman/.libs/lt-pacman -Sy
==15110== Memcheck, a memory error detector
==15110== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15110== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==15110== Command: ./src/pacman/.libs/lt-pacman -Sy
==15110== 
:: Synchronizing package databases...
 testing is up to date
 core is up to date
 extra is up to date
 community-testing is up to date
 multilib is up to date
 community is up to date
 testhttps is up to date
==15110== 
==15110== HEAP SUMMARY:
==15110==     in use at exit: 742,560 bytes in 3,021 blocks
==15110==   total heap usage: 4,568 allocs, 1,547 frees, 958,255 bytes allocated
==15110== 
==15110== 661,968 (632 direct, 661,336 indirect) bytes in 1 blocks are 
definitely lost in loss record 389 of 389
==15110==    at 0x4C2519D: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15110==    by 0x63E9FCD: CRYPTO_malloc (in /usr/lib/libcrypto.so.1.0.0)
==15110==    by 0x52A17EF: SSL_new (in /usr/lib/libssl.so.1.0.0)
==15110==    by 0x5059B51: fetch_ssl (in /usr/lib/libfetch.so)
==15110==    by 0x506009D: http_request (in /usr/lib/libfetch.so)
==15110==    by 0x506077B: fetchStatHTTP (in /usr/lib/libfetch.so)
==15110==    by 0x4E3F1E3: download_internal (dload.c:179)
==15110==    by 0x4E3FBE9: _alpm_download_single_file (dload.c:379)
==15110==    by 0x4E3825B: alpm_db_update (be_sync.c:124)
==15110==    by 0x40B725: pacman_sync (sync.c:273)
==15110==    by 0x4082E3: main (pacman.c:1464)
==15110== 
==15110== LEAK SUMMARY:
==15110==    definitely lost: 632 bytes in 1 blocks
==15110==    indirectly lost: 661,336 bytes in 420 blocks
==15110==      possibly lost: 0 bytes in 0 blocks
==15110==    still reachable: 80,592 bytes in 2,600 blocks
==15110==         suppressed: 0 bytes in 0 blocks
==15110== Reachable blocks (those to which a pointer was found) are not shown.
==15110== To see them, rerun with: --leak-check=full --show-reachable=yes
==15110== 
==15110== For counts of detected and suppressed errors, rerun with: -v
==15110== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 430 from 25)

>How-To-Repeat:
* fetch using any https:// URL.
>Fix:
I'm guessing add a #ifdef WITH_SSL to either fetch_close or http_closefn, and 
call SSL_free(conn->ssl) accordingly if it is not null.