tree 424b29038db2299542987e4256dbc11c499e2c82
parent ca2162d71902385dc740a385d20977d551d14e8f
author David Benjamin <davidben@google.com> 1613496008 -0500
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1613508626 +0000

Don't overflow the output length in EVP_CipherUpdate calls.

CVE-2021-23840

(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)

This differs slightly from upstream's version:

- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
  already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
  with compatibility anyway. Though there's probably something to be
  said for us folding CIPHER_R_* back into EVP_R_*.)

- For simplicity, just check in_len + bl at the top, rather than trying
  to predict the exact number of bytes written.

Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.

Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>