> I wrote that the next snapshots should solve the problem. Functions
>
> SSLv23_client_method(), SSLv23_server_method(),
> SSLv2_client_method(), SSLv2_server_method(),
> SSLv3_client_method(), SSLv3_server_method(),
> TLSv1_client_method(), TLSv1_server_method()
>
> now use a lock.
Bodo,
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
The functions now have:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
memcpy((char *)&SSLv3_client_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_client_data.ssl_connect=ssl3_connect;
SSLv3_client_data.get_ssl_method=ssl3_get_client_method;
init=0;
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
Two threads can enter init, and stop at the lock. One thread will get the
lock, set up client_data, exit the lock, and start using the struct. Then,
the other thread will get the lock, and mangle client_data while the first
thread is using it.
To prevent this, init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
....
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
