On Tue, Nov 24, 2015 at 11:06:44AM +0000, Pascal Cuoq via RT wrote:
> This issue is similar in nature to 4151 
> (http://www.mail-archive.com/openssl-dev@openssl.org/msg40950.html ): it is 
> about a dangling pointer being used, but not used for dereferencing, so it's 
> not a memory error. The dangling pointer is used in a comparison.
> 
> The function int_thread_del_item can reach the point were it calls 
> "lh_ERR_STATE_free(int_thread_hash);" with hash == int_thread_hash. That 
> attached patch prints a message like "hash == int_thread_hash == 0xb2a6d0" 
> when this happens. Just after the call to lh_ERR_STATE_free, both hash and 
> int_thread_hash contain dangling pointers. The variable int_thread_hash is 
> immediately set to NULL.
> 
> The problem that I am reporting is that just afterwards, &hash is passed to 
> the function int_thread_release:
> 
> https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412
> 
> In that function, the argument "hash" points to the local variable "hash" of 
> int_thread_del_item (which contains a dangling pointer).
> Thus the comparison "*hash == NULL" involves a dangling pointer:

I thinkt he following untested patch should fix that:
--- a/crypto/err/err.c
+++ b/crypto/err/err.c
@@ -403,8 +403,10 @@ static void int_thread_del_item(const
ERR_STATE *d)
         if (int_thread_hash_references == 1
             && int_thread_hash
             && lh_ERR_STATE_num_items(int_thread_hash) == 0) {
+            int_thread_hash_references = 0;
             lh_ERR_STATE_free(int_thread_hash);
             int_thread_hash = NULL;
+            hash = NULL;
         }
     }
     CRYPTO_w_unlock(CRYPTO_LOCK_ERR);


Kurt


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to