Fix double-free under load.

The BN_BLINDING cache, when 1024 threads are performing concurrent
private operations on one RSA key, can race to append a BN_BLINDING to a
cache which is just short of the maximum length. The cache ends up one
(or more) elements longer than the maximum length. That causes the index
of one of the cache elements to _be_ the supposed maximum length, but
that index is treated as a magic number that indicates that a
BN_BLINDING isn't from the cache and thus needs to be freed after use.
That BN_BLINDING is then double-freed when the cache itself is freed.

See internal bug b/147126942.

Since the fact that someone hit this means that 1024 threads working on
a single RSA key is a thing that's happening, take the opportunity to
grow the cache by doubling rather than by single elements at a time.
Once the number of extensions is so reduced, the trick of unlocking to
keep a few allocations outside of the lock (which caused the problem)
can be discarded.

Change-Id: I32dd16d825b702b31ee9b776414c4e6afe883724
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39324
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2 files changed
tree: 321beb6fffff4fbc619aa3b7b90a111187973074
  1. .clang-format
  2. .github/
  3. .gitignore
  4. API-CONVENTIONS.md
  5. BREAKING-CHANGES.md
  6. BUILDING.md
  7. CMakeLists.txt
  8. CONTRIBUTING.md
  9. FUZZING.md
  10. INCORPORATING.md
  11. LICENSE
  12. PORTING.md
  13. README.md
  14. STYLE.md
  15. codereview.settings
  16. crypto/
  17. decrepit/
  18. fuzz/
  19. go.mod
  20. include/
  21. sources.cmake
  22. ssl/
  23. third_party/
  24. tool/
  25. util/
README.md

BoringSSL

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Project links:

There are other files in this directory which might be helpful: