Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
nss: only cache valid CRL entries #4053
Conversation
| /* 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); |
kdudka
Jun 20, 2019
•
Collaborator
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);
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);
danielgustafsson
Jun 20, 2019
Author
Member
Ah, nice catch, fixed and rebased.
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
danielgustafsson
force-pushed the
danielgustafsson:dg-nss_crl_cache
branch
from
19f1cda
to
f33f352
|
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. Closes curl#4053
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.