cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH] Correct refcount issues when using client certs in NSS

From: Claes Jakobsson <claes_at_versed.se>
Date: Sat, 30 May 2009 17:06:40 +0200

Hi Kamil

On 30 maj 2009, at 15.27, Kamil Dudka wrote:
> I am not sure if I understand it enough. I have no problem with the
> hunk #1
> of your patch, it does the right thing anyway. But why do you want to
> duplicate the certificate? There is a reference counter, so the
> certificate
> should be available until CERT_DestroyCertificate() is called. It is
> called
> in the Curl_nss_close() function. The problem must be elsewhere.

Well, from what I can dig out of the sources NSS calls
CERT_DestroyCertificate internally on the cert returned from the
callback (see for example the end of ssl2_HandleRequestCertificate in
lib/ssl/sslcon.c) which is why we must retain the certificate using
CERT_DupCertificate if we want to keep it around as it's done in
curl's nss implementation.

What kind of certificates are leaking memory for you - those loaded
from a PEM file or ones that are already in a NSS store?

> It would be good to get some more details about the crash -
> backtrace, etc.
> Does it work properly with the duplicated certificate? Could you
> please try
> to set the NSS_DEBUG_PKCS11_MODULE environment variable to the name
> of PKCS11
> module you are using?

It's the second connection when it finds the certificate in the
session cache that it seg. faults because the cert has been destroyed
when we closed the connection last time which is why it's actually
CERT_DupCertificate that fails and not CERT_DestroyCertificate.

Here's what GDB tells me:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xdadadade
__PR_Darwin_x86_AtomicIncrement () at ../../../../../pr/src/md/unix/
os_Darwin_x86.s:49
49 ../../../../../pr/src/md/unix/os_Darwin_x86.s: No such file or
directory.
        in ../../../../../pr/src/md/unix/os_Darwin_x86.s
(gdb) bt
#0 __PR_Darwin_x86_AtomicIncrement () at ../../../../../pr/src/md/
unix/os_Darwin_x86.s:49
#1 0x005f9ea7 in PR_AtomicIncrement (val=0xdadadade) at ../../../../
pr/src/misc/pratom.c:306
#2 0x003fccc9 in nssPKIObject_AddRef (object=0xdadadada) at pkibase.c:
192
#3 0x003f5c55 in nssCertificate_AddRef (c=0xdadadada) at
certificate.c:112
#4 0x003e5880 in CERT_DupCertificate (c=0x893610) at certdb.c:1377
#5 0x0031cecf in ssl2_BeginClientHandshake (ss=0x8a4e00) at sslcon.c:
3093
#6 0x0032388e in ssl_Do1stHandshake (ss=0x8a4e00) at sslsecur.c:151
#7 0x0032418b in SSL_ForceHandshake (fd=0x29d0c0) at sslsecur.c:407
#8 0x003241f6 in SSL_ForceHandshakeWithTimeout (fd=0x29d0c0,
timeout=30000) at sslsecur.c:428
#9 0x0019cd20 in Curl_nss_connect (conn=0x811804, sockindex=0) at
nss.c:1211
#10 0x00196b30 in Curl_ssl_connect (conn=0x811804, sockindex=0) at
sslgen.c:185
#11 0x0016b712 in Curl_http_connect (conn=0x811804, done=0xbffff34a)
at http.c:1804
#12 0x0017b356 in Curl_protocol_connect (conn=0x811804,
protocol_done=0xbffff34a) at url.c:3021
#13 0x0017dd5a in setup_conn (conn=0x811804, hostaddr=0x25a8b4,
protocol_done=0xbffff34a) at url.c:4652
#14 0x0017dec5 in Curl_connect (data=0x64e004, in_connect=0xbffff388,
asyncp=0xbffff34b, protocol_done=0xbffff34a) at url.c:4728
#15 0x00189407 in connect_host (data=0x64e004, conn=0xbffff388) at
transfer.c:2481
#16 0x001895b6 in Curl_perform (data=0x64e004) at transfer.c:2562
#17 0x00189fb3 in curl_easy_perform (curl=0x64e004) at easy.c:552
#18 0x0015806a in XS_WWW__Curl__Easy_perform ()
#19 0x0007aff5 in Perl_pp_entersub ()
#20 0x000721e5 in Perl_runops_standard ()
#21 0x0006e563 in perl_run ()
#22 0x00001dfe in main ()

I've attached the PKCS11 debug log (but with some some cert and token
names removed)

/Claes

Received on 2009-05-30