Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correctly free EVP_MD_CTX in OpenSSL #501

Merged
merged 2 commits into from
Jul 22, 2019
Merged

Conversation

ilammy
Copy link
Collaborator

@ilammy ilammy commented Jul 18, 2019

soter_sign_ctx_t structures store both EVP_MD_CTX (to keep the digest algorithm used for signatures) and EVP_PKEY_CTX (to keep the key used for signature). The key is actually shared between those structures but EVP_MD_CTX assumes ownership over it, with EVP_MD_CTX_destroy() freeing the key. EVP_PKEY structures are refcounted so sharing the key should be safe... if we make the correct precautions to avoid freeing the key after it has been freed. EVP_PKEY_CTX keeps track of that, but we need to free EVP_MD_CTX first and then proceed to freeing EVP_PKEY_CTX and maybe the key it has been managing.

tl;dr: manual memory management is hard.

This sleeper bug is presumed to be responsible for occasional segfaults when running JsThemis. Interestingly, the crashes do not reproduce with any other wrapper. Furthermore, BoringSSL code uses correct freeing order since the beginning. "Coincidence? I don't think so".

soter_sign_ctx_t structures store both EVP_MD_CTX (to keep the digest
algorithm used for signatures) and EVP_PKEY_CTX (to keep the key used
for signature). The key is actually shared between those structures
but EVP_MD_CTX assumes ownership over it, with EVP_MD_CTX_destroy()
freeing the key. EVP_PKEY structures are refcounted so sharing the
key should be safe... if we make the correct precautions to avoid
freeing the key after it has been freed. EVP_PKEY_CTX keeps track
of that, but we need to free EVP_MD_CTX first and then proceed to
freeing EVP_PKEY_CTX and maybe the key it has been managing.

This sleeper bug is presumed to be responsible for occasional segfaults
when running JsThemis. Interestingly, the crashes do not reproduce with
any other wrapper. Furthermore, BoringSSL code uses correct freeing
order since the beginning. "Coincidence? I don't think so".
@ilammy ilammy added the core Themis Core written in C, its packages label Jul 18, 2019
@ilammy ilammy requested a review from vixentael July 18, 2019 14:36
Copy link
Contributor

@vixentael vixentael left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is very mysterious bug indeed. i think we also should monitor BuildBot cross-platform & cross-version tests, just to make sure that all is ok

@ignatk
Copy link
Contributor

ignatk commented Jul 18, 2019

Maybe we should consider running tests under some kind of leak detector.

@Lagovas
Copy link
Collaborator

Lagovas commented Jul 22, 2019

we already use valgrind for leak detection

@ilammy ilammy merged commit 914d799 into cossacklabs:master Jul 22, 2019
@ilammy ilammy deleted the evp-usage branch July 22, 2019 11:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Themis Core written in C, its packages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants