Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
3.0.3
-
None
-
None
Description
ssl_thread_init() uses wrong openssl threadid callback
The ssl_thread_init() sets thread and locking callbacks after checking whether
the application has already set its own thread callbacks.
Indeed it is correct to do the check and step back if the application has
installed callbacks already. The problem with the check is that it is
implemented incorrectly using the deprecated function CRYPTO_get_id_callback(),
which has been deprecated since version 1.0.0.
The consequence is that the check does not work when the application uses
the newer api (CRYPTO_THREADID_set_callback()). In my case both the
application and the connector set their own locking callbacks which
led to an application crash on application exit.
The attached patch fixes the check in a defensive way by checking for
both legacy callbacks and new style callbacks. It also fixes another location
where the deprecated api was used erroneously.
Index: mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c
|
===================================================================
|
--- mariadb-connector-c-3.0.3-src.orig/libmariadb/secure/openssl.c
|
+++ mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c
|
@@ -255,7 +255,11 @@ static void my_cb_locking(int mode, int
|
|
static int ssl_thread_init()
|
{
|
- if (!CRYPTO_get_id_callback())
|
+ if (!CRYPTO_THREADID_get_callback()
|
+#ifndef OPENSSL_NO_DEPRECATED
|
+ && !CRYPTO_get_id_callback()
|
+#endif
|
+ )
|
{
|
int i, max= CRYPTO_num_locks();
|
|
@@ -382,7 +386,7 @@ void ma_tls_end()
|
{
|
int i;
|
CRYPTO_set_locking_callback(NULL);
|
- CRYPTO_set_id_callback(NULL);
|
+ CRYPTO_THREADID_set_callback(NULL);
|
for (i=0; i < CRYPTO_num_locks(); i++)
|
pthread_mutex_destroy(&LOCK_crypto[i]);
|
ma_free((gptr)LOCK_crypto);
|
|
Attachments
Activity
Field | Original Value | New Value |
---|---|---|
Summary | ssl_thread_init() use uses wrong openssl threadid callback | ssl_thread_init() uses wrong openssl threadid callback |
Description |
ssl_thread_init() use uses wrong openssl threadid callback
The ssl_thread_init() sets thread and locking callbacks after checkin whether the application has already set its own thread callbacks. Indeed it is correct to do the check and step back if the application has installed callbacks already. The problem with the check is that it is implemented incorrectly using the deprecated function CRYPTO_get_id_callback(), which has been deprecated since version 1.0.0. The consequence is that the check does not work when the application uses the newer api (CRYPTO_THREADID_set_callback()). In my case both the application and the connector set their own locking callbacks which led to an application crash on application exit. The attached patch fixes the check in a defensive way by checking for both legacy callbacks and new style callbacks. It also fixes another location where the deprecated api was used erroneously. {noformat} Index: mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c =================================================================== --- mariadb-connector-c-3.0.3-src.orig/libmariadb/secure/openssl.c +++ mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c @@ -255,7 +255,11 @@ static void my_cb_locking(int mode, int static int ssl_thread_init() { - if (!CRYPTO_get_id_callback()) + if (!CRYPTO_THREADID_get_callback() +#ifndef OPENSSL_NO_DEPRECATED + && !CRYPTO_get_id_callback() +#endif + ) { int i, max= CRYPTO_num_locks(); @@ -382,7 +386,7 @@ void ma_tls_end() { int i; CRYPTO_set_locking_callback(NULL); - CRYPTO_set_id_callback(NULL); + CRYPTO_THREADID_set_callback(NULL); for (i=0; i < CRYPTO_num_locks(); i++) pthread_mutex_destroy(&LOCK_crypto[i]); ma_free((gptr)LOCK_crypto); {noformat} |
ssl_thread_init() uses wrong openssl threadid callback
The ssl_thread_init() sets thread and locking callbacks after checking whether the application has already set its own thread callbacks. Indeed it is correct to do the check and step back if the application has installed callbacks already. The problem with the check is that it is implemented incorrectly using the deprecated function CRYPTO_get_id_callback(), which has been deprecated since version 1.0.0. The consequence is that the check does not work when the application uses the newer api (CRYPTO_THREADID_set_callback()). In my case both the application and the connector set their own locking callbacks which led to an application crash on application exit. The attached patch fixes the check in a defensive way by checking for both legacy callbacks and new style callbacks. It also fixes another location where the deprecated api was used erroneously. {noformat} Index: mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c =================================================================== --- mariadb-connector-c-3.0.3-src.orig/libmariadb/secure/openssl.c +++ mariadb-connector-c-3.0.3-src/libmariadb/secure/openssl.c @@ -255,7 +255,11 @@ static void my_cb_locking(int mode, int static int ssl_thread_init() { - if (!CRYPTO_get_id_callback()) + if (!CRYPTO_THREADID_get_callback() +#ifndef OPENSSL_NO_DEPRECATED + && !CRYPTO_get_id_callback() +#endif + ) { int i, max= CRYPTO_num_locks(); @@ -382,7 +386,7 @@ void ma_tls_end() { int i; CRYPTO_set_locking_callback(NULL); - CRYPTO_set_id_callback(NULL); + CRYPTO_THREADID_set_callback(NULL); for (i=0; i < CRYPTO_num_locks(); i++) pthread_mutex_destroy(&LOCK_crypto[i]); ma_free((gptr)LOCK_crypto); {noformat} |
Fix Version/s | 3.0.4 [ 22922 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
issue.field.resolutiondate | 2018-04-24 10:23:02.0 | 2018-04-24 10:23:02.836 |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Workflow | MariaDB connectors [ 86729 ] | MariaDB v4 [ 161114 ] |