summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorjwalch <jeremy.walch@gmail.com>2020-10-29 13:32:49 -0400
committerTomas Mraz <tmraz@fedoraproject.org>2020-11-02 18:03:22 +0100
commit3d7e7e7c48210b515ef5e05f4acf6dc58377331c (patch)
treed4c5bc6b4ac11433146086911702ece5679dec4f
parentd1ca391123864180d7d1d61c84e127ffcf2967d6 (diff)
Prevent potential UAF in init_thread_deregister()
I discovered the potential for use-after-free on glob_tevent_reg & its members in this function as a consequence of some static (de-)initialization fiasco in C++ client code. Long story short, an EVP_PKEY_free() was happening after OPENSSL_cleanup(). Aside from being freed the EVP_PKEY object wasn't actually being used after cleanup, it was basically just an ordering issue. Obviously the application behavior here is somewhat suspect, but IMO is basically benign. Crashing (most typical outcome of a UAF) doesn't seem the optimal response. At any rate, the issue can be avoided (at least with regard to this function) by simply updating the pointer to NULL rather than leaving it pointing to the freed memory, as is the typical practice. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13267)
-rw-r--r--crypto/initthread.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/crypto/initthread.c b/crypto/initthread.c
index f460252ff9..93160f577c 100644
--- a/crypto/initthread.c
+++ b/crypto/initthread.c
@@ -389,6 +389,8 @@ static int init_thread_deregister(void *index, int all)
return 0;
if (!all)
CRYPTO_THREAD_write_lock(gtr->lock);
+ else
+ glob_tevent_reg = NULL;
for (i = 0; i < sk_THREAD_EVENT_HANDLER_PTR_num(gtr->skhands); i++) {
THREAD_EVENT_HANDLER **hands
= sk_THREAD_EVENT_HANDLER_PTR_value(gtr->skhands, i);