Package: libcurl4-gnutls Version: 7.16.2-3 Severity: important Tags: upstream
In Curl_disconnect() (lib/url.c) in line 1884 Curl_ssl_close() is called. However just a bit further, in line 1892 conn_free() is called, which itself calls Curl_ssl_close() in 1804. This may lead a to nasty double-free, which aborts the application when glibc checks it (but is wrong even if it's not checked for). An example from sms-pl: ==14306== Invalid free() / delete / delete[] ==14306== at 0x40230CA: free (vg_replace_malloc.c:233) ==14306== by 0x439110B: gnutls_deinit (gnutls_state.c:420) ==14306== by 0x40529C4: close_one (gtls.c:503) ==14306== by 0x4052A1B: Curl_gtls_close (gtls.c:511) ==14306== by 0x4053765: Curl_ssl_close (sslgen.c:418) ==14306== by 0x403CB5E: conn_free (url.c:1804) ==14306== by 0x403CC83: Curl_disconnect (url.c:1892) ==14306== by 0x403CFB8: ConnectionKillOne (url.c:2239) ==14306== by 0x4041236: Curl_close (url.c:219) ==14306== by 0x4049E90: curl_easy_cleanup (easy.c:504) ==14306== by 0x8065832: Curl::~Curl() (mr_curl.cc:269) ==14306== by 0x80504D2: GenericSMS::~GenericSMS() (generic_sms.h:25) ==14306== Address 0x45F8620 is 0 bytes inside a block of size 2,704 free'd ==14306== at 0x40230CA: free (vg_replace_malloc.c:233) ==14306== by 0x439110B: gnutls_deinit (gnutls_state.c:420) ==14306== by 0x40529C4: close_one (gtls.c:503) ==14306== by 0x4052A1B: Curl_gtls_close (gtls.c:511) ==14306== by 0x4053765: Curl_ssl_close (sslgen.c:418) ==14306== by 0x403CC71: Curl_disconnect (url.c:1884) ==14306== by 0x403CFB8: ConnectionKillOne (url.c:2239) ==14306== by 0x4041236: Curl_close (url.c:219) ==14306== by 0x4049E90: curl_easy_cleanup (easy.c:504) ==14306== by 0x8065832: Curl::~Curl() (mr_curl.cc:269) ==14306== by 0x80504D2: GenericSMS::~GenericSMS() (generic_sms.h:25) ==14306== by 0x8062D72: OrangemboxSMS::~OrangemboxSMS() (orangembox.h:7) In case you're not familiar with valgrind, the first stack trace is when free is called second time, and the second stack trace is when the memory block was free()d initially. A big heap of valgrind memory access errors reports are available at http://marcin.owsiany.pl/tmp/sms-valgrind-01.log in case you are interested. (you should probably ignore a dozen or so of the ones at the beginning, as they seem unrelated to curl). Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
