-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Return NULL early in context_preallocated_create if flags invalid #840
Return NULL early in context_preallocated_create if flags invalid #840
Conversation
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.
Concept ACK, but the newly introduced VERIFY_CHECK
is wrong, causing tests to fail.
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.
Looks good to me. Local tests pass with the !=
-> ==
fix.
If the user passes invalid flags to _context_create, and the default illegal callback does not abort the program (which is possible), then we work with the result of malloc(0), which may be undefined behavior. This violates the promise that a library function won't crash after the illegal callback has been called. This commit fixes this issue by returning NULL early in _context_create in that case.
246b081
to
ebfa205
Compare
Fixed... |
ACK ebfa205 |
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.
ACK ebfa205
Should the header at secp256k1_preallocated.h indicate that this can return a null pointer on error? (I guess it could before too, but it appears to be undocumented.) |
The same is true for the the normal But the docs are really difficult to understand here. We give a promise that the illegal callback "will only trigger for violations that are mentioned explicitly in the header." and this is not really mentioned (or at least) it's not very implicit. We may want to add a sentence for each function can calls the illegal callback but I don't know if we want to commit on this... I suggest to discuss this in #783. |
K. Just thought I'd mention it. |
… invalid Summary: ``` If the user passes invalid flags to _context_create, and the default illegal callback does not abort the program (which is possible), then we work with the result of malloc(0), which may be undefined behavior. This violates the promise that a library function won't crash after the illegal callback has been called. This commit fixes this issue by returning NULL early in _context_create in that case. ``` Backport of secp256k1 [[bitcoin-core/secp256k1#840 | PR840]]. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D8202
… invalid Summary: ``` If the user passes invalid flags to _context_create, and the default illegal callback does not abort the program (which is possible), then we work with the result of malloc(0), which may be undefined behavior. This violates the promise that a library function won't crash after the illegal callback has been called. This commit fixes this issue by returning NULL early in _context_create in that case. ``` Backport of secp256k1 [[bitcoin-core/secp256k1#840 | PR840]]. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D8202
If the user passes invalid flags to _context_create, and the default
illegal callback does not abort the program (which is possible), then we
work with the result of malloc(0), which may be undefined behavior. This
violates the promise that a library function won't crash after the
illegal callback has been called.
This commit fixes this issue by returning NULL early in _context_create
in that case.