Fix mutex thread lock in drbg_uninstantiate function.#144
Fix mutex thread lock in drbg_uninstantiate function.#144vkanjur wants to merge 1 commit intoopencryptoki:masterfrom
Conversation
This commit is to unlock the thread mutex in the drbg_uninstantiate function after the mechanism specific uninstantiate call. Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
| pthread_mutex_lock(&(*sh)->lock); | ||
| status = (*sh)->mech->uninstantiate(&(*sh)->ws, test_mode); | ||
| pthread_mutex_unlock(&(*sh)->lock); | ||
| pthread_mutex_destroy(&(*sh)->lock); |
There was a problem hiding this comment.
I wonder if we really should destroy the lock here, and zero the memory in the error return.
If we destroy the lock here, and mech->uninstantiate() has failed (practically impossible, so just theoretically speaking), then we return with an error below and have cleared *sh, but not freed it.
With *sh cleared, if the caller attempts to call drbg_uninstantiate() again, the if at step 1 already terminates the call with an error again. So *sh will never be freed.
However, if we just unlock the lock before the status check, but don't destroy it, and if we also don't zero *sh in the error case, then the contents of *sh would stay valid and the caller could call drbg_uninstantiate() again, and it would try the mech->uninstantiate() again. If (for whatever reason - e.g. because it is now in error state) it now succeeds, then it would go on and finally free *sh. Certainly if mech->uninstantiate() keeps failing, then this won't help and you still would never reach the place to free *sh....
2 participants
This commit is to unlock the thread mutex in the drbg_uninstantiate function after the mechanism specific uninstantiate call.