Fix BIO_f_cipher flushing and other BIO related fixes#19918
Fix BIO_f_cipher flushing and other BIO related fixes#19918mattcaswell wants to merge 6 commits intoopenssl:masterfrom
Conversation
|
I am confused by the test failures.... |
If an error occurs during a flush on a BIO_f_cipher() then in some cases we could get into an infinite loop. We add a check to make sure we are making progress during flush and exit if not. This issue was reported by Octavio Galland who also demonstrated an infinite loop in CMS encryption as a result of this bug. The security team has assessed this issue as not a CVE. This occurs on *encryption* only which is typically processing trusted data. We are not aware of a way to trigger this with untrusted data.
If the BIO unexpectedly fails to flush then SMIME_crlf_copy() was not correctly reporting the error. We modify it to properly propagate the error condition.
Some things that may go wrong in asn1_bio_write() are serious errors that should be reported as -1, rather than 0 (which just means "we wrote no data").
If the cipher being used in ossl_cms_EncryptedContent_init_bio() has no associated OID then we should report an error rather than continuing on regardless. Continuing on still ends up failing - but later on and with a more cryptic error message.
89754cd to
754d694
Compare
Interesting. This seems to be due to a bad interaction with #19652 which was merged after my local branch containing this fix was created. Github Actions automatically merge a PR with the master branch during the CI run and there were no conflicts but having both in the tree at the same time causes a test failure because of a bad plan (17 tests were run when it expected 16). Rebasing my local branch reproduced the issue. Fixup pushed. |
| } | ||
| } | ||
| (void)BIO_flush(out); | ||
| ret = BIO_flush(out); |
There was a problem hiding this comment.
I dont know if it matters but there are quite a few other (void)BIO_flush calls related to cms/pkcs7
|
24 hours has passed since 'approval: done' was set, but this PR has failing CI tests. Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually. |
|
This pull request is ready to merge |
|
Merged to master branch. Thank you. |
If an error occurs during a flush on a BIO_f_cipher() then in some cases we could get into an infinite loop. We add a check to make sure we are making progress during flush and exit if not. This issue was reported by Octavio Galland who also demonstrated an infinite loop in CMS encryption as a result of this bug. The security team has assessed this issue as not a CVE. This occurs on *encryption* only which is typically processing trusted data. We are not aware of a way to trigger this with untrusted data. Reviewed-by: Hugo Landau <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #19918)
If the BIO unexpectedly fails to flush then SMIME_crlf_copy() was not correctly reporting the error. We modify it to properly propagate the error condition. Reviewed-by: Hugo Landau <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #19918)
Some things that may go wrong in asn1_bio_write() are serious errors that should be reported as -1, rather than 0 (which just means "we wrote no data"). Reviewed-by: Hugo Landau <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #19918)
If the cipher being used in ossl_cms_EncryptedContent_init_bio() has no associated OID then we should report an error rather than continuing on regardless. Continuing on still ends up failing - but later on and with a more cryptic error message. Reviewed-by: Hugo Landau <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #19918)
Reviewed-by: Hugo Landau <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #19918)
If an error occurs during a flush on a BIO_f_cipher() then in some cases
we could get into an infinite loop. We add a check to make sure we are
making progress during flush and exit if not.
This issue was reported by Octavio Galland who also demonstrated an
infinite loop in CMS encryption as a result of this bug.
The security team has assessed this issue as not a CVE. This occurs on
encryption only which is typically processing trusted data. We are not
aware of a way to trigger this with untrusted data.