Thanks, I can repeat it at will now. But I haven't quite worked out what the suitable way forward is.

I don't quite understand how we are supposed to deal with the list we get back in the 'ca' argument to the PKCS12_parse() call.

If we call sk_X509_pop_free() like today (I do have a cleaned up code patch to propose but that isn't strictly relevant so I'll save that for now) we get the error you report here, but if we remove the call completely we instead get a memory leak! Have you figured out what the correct logic is?

---
** [bugs:#1236] Curl double-free with pkcs12 handling**
**Status:** open
**Created:** Fri May 31, 2013 10:06 PM UTC by Nikaiw
**Last Updated:** Mon Jun 10, 2013 12:45 PM UTC
**Owner:** Daniel Stenberg
Summary :
-------
There is a double free bug in curl when using p12 client certificate to connect to an https server.
Steps to reproduce :
------------------
Connect to any https server using a client certificate in pkcs12 format.
curl -vvv --cert yourcertificate.p12:yourpassword --cert-type P12 https://yourserver.com
eg:
* About to connect() to ************ port 443 (#0)
*   Trying **********...
* Connected to ********** (*.*.*.*) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Erreur de segmentation (core dumped)
Bug is 100% reproducible.
Affected version :
----------------
Affected version are curl-7.24 to 7.30. 
Details :
--------
Bug was introduced in following commit to fix a memory leak: 
https://github.com/bagder/curl/commit/6ea7acf5a96786f7514be4fbce174cdc8bedfdd1
on line 512 of ssluse.c:  sk_X509_pop_free(ca, X509_free);
curl is freeing data related to the handling of the certificate which may have already being freed by SSL_CTX_free call made on line 865 of ssluse.c when we are closing the ssl connexion.
Here is a valgrind stacktrace:
==4136== Invalid free() / delete / delete[] / realloc()
==4136==    at 0x4C2BA6C: free (vg_replace_malloc.c:446)
==4136==    by 0x5B964EC: CRYPTO_free (mem.c:397)
==4136==    by 0x5C4029F: asn1_item_combine_free (tasn_fre.c:176)
==4136==    by 0x5C40484: ASN1_item_free (tasn_fre.c:71)
==4136==    by 0x5C1E96F: sk_pop_free (stack.c:283)
==4136==    by 0x590F806: SSL_CTX_free (ssl_lib.c:1947)
==4136==    by 0x4E67BD4: Curl_ossl_close (ssluse.c:865)
==4136==    by 0x4E89822: Curl_ssl_close (sslgen.c:421)
==4136==    by 0x4E60906: Curl_disconnect (url.c:2565)
==4136==    by 0x4E81B40: multi_runsingle (multi.c:1637)
==4136==    by 0x4E81D54: curl_multi_perform (multi.c:1708)
==4136==    by 0x4E76CDC: curl_easy_perform (easy.c:448)
==4136==  Address 0x6636d00 is 0 bytes inside a block of size 184 free'd
==4136==    at 0x4C2BA6C: free (vg_replace_malloc.c:446)
==4136==    by 0x5B964EC: CRYPTO_free (mem.c:397)
==4136==    by 0x5C4029F: asn1_item_combine_free (tasn_fre.c:176)
==4136==    by 0x5C40484: ASN1_item_free (tasn_fre.c:71)
==4136==    by 0x5C1E96F: sk_pop_free (stack.c:283)
==4136==    by 0x4E67378: cert_stuff (ssluse.c:510)
==4136==    by 0x4E68F54: ossl_connect_step1 (ssluse.c:1524)
==4136==    by 0x4E6BBC8: ossl_connect_common (ssluse.c:2433)
==4136==    by 0x4E6BE46: Curl_ossl_connect_nonblocking (ssluse.c:2522)
==4136==    by 0x4E890A2: Curl_ssl_connect_nonblocking (sslgen.c:218)
==4136==    by 0x4E49D5C: https_connecting (http.c:1345)
==4136==    by 0x4E49CBA: Curl_http_connect (http.c:1315)
I'm not sure the bug is exploitable nor i see any practical case.
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1236/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>