[openssl-dev] [openssl.org #4495] After upgrade openssl to 1.0.2g, it cause core accidently, please help me !

[Matt Caswell via RT]

On 31/03/16 14:00, Hejian via RT wrote:
> Hello, when upgrade openssl to 1.0.2g, If multi thread call the corba
> interface, it will cause core accidently. Please help analyze why the
> core is generated.
> 
> There are two kinds of core stack list below.
> 
> 
> #0  0x00007f97729ad324 in RSA_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #1
> 0x00007f97729b2c13 in pkey_rsa_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #2
> 0x00007f97729e1e6a in EVP_DigestVerifyFinal () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #3
> 0x00007f97729ec0d0 in ASN1_item_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #4
> 0x00007f9772a0b7f2 in internal_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #5
> 0x00007f9772a0d03a in X509_verify_cert () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #6
> 0x00007f97727aed68 in ssl_verify_cert_chain () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #7  0x00007f977278a486
> in ssl3_get_server_certificate () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #8  0x00007f977278da22
> in ssl3_connect () from /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 
> #9  0x00007f977279797a in ssl23_connect () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #10 0x00007f97719ad764
> in ACE_SSL_SOCK_Connector::ssl_connect(ACE_SSL_SOCK_Stream&,
> ACE_Time_Value const*) ()
> 
> The first core stack, we suspect there is NULL ptr use in
> internal_verify function:
> 
> when first thread run in X509_PUBKEY_get and create key->pkey, and go
> to EVP_PKEY_free(pkey); At same time another thread run to below
> function find key->pkey not NULL, get the value, and not goto add
> reference. The first thread think the reference decrease to 0 and
> free it. The second thread will call NULL ptr and cause core. Please
> help confirm whether my analyze is correct and why here is a core?
> 
> /* Check to see if another thread set key->pkey first */ 
> CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY); if (key->pkey) { 
> CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY); EVP_PKEY_free(ret); ret =
> key->pkey; } else { key->pkey = ret; 
> CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY); } CRYPTO_add(&ret->references,
> 1, CRYPTO_LOCK_EVP_PKEY);
> 

So you think pkey ends up being NULL? Is that just a theory or have you
verified that in a debugger? I can't immediately see a problem with the
above code - the reference counting looks ok to me. Don't forget when
EVP_PKEY_new() gets called the reference count starts off as 1, and in
order to return from the X509_PUBKEY_get() function you must have
incremented the reference count by an additional 1 (no matter in which
order the threads complete the function). Furthermore the
ASN1_item_verify() function in the above stack trace verifies that pkey
!= NULL before it gets as far as calling EVP_DigestVerifyFinal().

Are you able to recompile OpenSSL with debugging symbols included (i.e.
pass the "-d" flag to "config" when building). That may help narrow
things down a bit.


> 
> The second stack we can't find why it cause core, please help analyze
> the source code where may cause core? #0  0x00007f84a332bf2d in

Without debugging symbols it is difficult to say much about this one.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4495
Please log in as guest with password guest if prompted