commit 2c58c2fda1c1da4131f35f58289f44d87cedbb8d
author Adam Langley <agl@google.com> Fri Jan 03 14:53:04 2020 -0800
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Mon Jan 06 17:34:02 2020 +0000
tree 321beb6fffff4fbc619aa3b7b90a111187973074
parent aaa1a84d63dbc74ea1c15fd7c421ee59902e910d

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>