diff options
| author | Matt Caswell <matt@openssl.org> | 2021-11-09 14:32:14 +0000 |
|---|---|---|
| committer | Matt Caswell <matt@openssl.org> | 2021-11-15 14:22:41 +0000 |
| commit | 256ec496890da13c700d5a21b069d519fe02c0b2 (patch) | |
| tree | 2a6cbee3eb479e776482596213882e5ff08d8b2f | |
| parent | 5ab06d33e6b3be15c8784f1e1fd6c3d845b5cc3a (diff) | |
Use a write lock during ossl_provider_find()
A "find" operation on a stack can end up sorting the underlying stack. In
this case it is necessary to use a "write" lock to synchronise access to
the stack across multiple threads.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17018)
| -rw-r--r-- | crypto/provider_core.c | 6 | ||||
| -rw-r--r-- | doc/man3/DEFINE_STACK_OF.pod | 5 |
2 files changed, 9 insertions, 2 deletions
diff --git a/crypto/provider_core.c b/crypto/provider_core.c index 127c7c9aba..a11676d03c 100644 --- a/crypto/provider_core.c +++ b/crypto/provider_core.c @@ -424,7 +424,11 @@ OSSL_PROVIDER *ossl_provider_find(OSSL_LIB_CTX *libctx, const char *name, #endif tmpl.name = (char *)name; - if (!CRYPTO_THREAD_read_lock(store->lock)) + /* + * A "find" operation can sort the stack, and therefore a write lock is + * required. + */ + if (!CRYPTO_THREAD_write_lock(store->lock)) return NULL; if ((i = sk_OSSL_PROVIDER_find(store->providers, &tmpl)) != -1) prov = sk_OSSL_PROVIDER_value(store->providers, i); diff --git a/doc/man3/DEFINE_STACK_OF.pod b/doc/man3/DEFINE_STACK_OF.pod index d7152466f4..ec9eda81c6 100644 --- a/doc/man3/DEFINE_STACK_OF.pod +++ b/doc/man3/DEFINE_STACK_OF.pod @@ -178,7 +178,10 @@ where a comparison function has been specified, I<sk> is sorted and B<sk_I<TYPE>_find>() returns the index of a matching element or B<-1> if there is no match. Note that, in this case the comparison function will usually compare the values pointed to rather than the pointers themselves and -the order of elements in I<sk> can change. +the order of elements in I<sk> can change. Note that because the stack may be +sorted as the result of a B<sk_I<TYPE>_find>() call, if a lock is being used to +synchronise access to the stack across multiple threads, then that lock must be +a "write" lock. B<sk_I<TYPE>_find_ex>() operates like B<sk_I<TYPE>_find>() except when a comparison function has been specified and no matching element is found. |