-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
nss: only cache valid CRL entries #4053
Conversation
lib/vtls/nss.c
Outdated
/* unable to cache CRL */ | ||
/* store the CRL item so that we can free it in Curl_nss_cleanup() */ | ||
if(insert_wrapped_ptr(&nss_crl_list, crl_der) != CURLE_OK) { | ||
SECITEM_FreeItem(crl_der, PR_TRUE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to call CERT_UncacheCRL()
before releasing the memory to avoid a possible use after free later on. If CERT_UncacheCRL()
fails, which is unlikely, it is IMO better to leak the memory. Something like:
if(SECSuccess == CERT_UncacheCRL(db, crl_der))
SECITEM_FreeItem(crl_der, PR_TRUE);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, nice catch, fixed and rebased.
Change the logic around such that we only keep CRLs that NSS actually ended up caching around for later deletion. If CERT_CacheCRL() fails then there is little point in delaying the freeing of the CRL as it is not used. Closes #xxxx
19f1cda
to
f33f352
Compare
A thing to note which I failed to write in the commitmessage (but will amend before pushing if approved) is that without this we leave a dangling pointer on |
I do not understand the above note. Are you talking about the original implementation? It did not (immediately) call |
On 20 Jun 2019, at 15:16, Kamil Dudka ***@***.***> wrote:
I do not understand the above note. Are you talking about the original implementation? It did not (immediately) call SECITEM_FreeItem() upon failure of CERT_CacheCRL(). The only problem was that the memory was released too late as I understand it.
Sorry, I managed to confuse myself reading the code - the original implementation did indeed not have such a bug. I clearly need more coffee today..
|
No problem, thank you for clarifying it! And thank you for improving the code! |
Thanks |
Change the logic around such that we only keep CRLs that NSS actually ended up caching around for later deletion. If CERT_CacheCRL() fails then there is little point in delaying the freeing of the CRL as it is not used.