There is a race condition in X509_PUBKEY_get that can result in leaked memory.
It is present in versions 0.9.8d and 0.9.7l for sure, but I believe it is much older (possibly from the first version of this function). The problem is around line 370 in openssl-0.9.8d/crypto/asn1/x_pubkey.c and it has to do with "key->pkey". At a high level, the problem is that this field is lazy allocated but with no locking to control it properly. If two threads execute X509_PUBKEY_get on a certificate that has no key cached in "key->pkey", they will both allocate new EVP_PKEY structures with a refcount of 2 to return to their caller. Only one of them will win the race on line 370 to attach it to the X509_PUBKEY which means that the other one will leak (it will end up with a refcount of 1 and nobody holding a pointer to it). I'm not sure which of the static locks should be used to fix this problem, but some additional locking is definitely required here. -Ivan Nestlerode ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
