[openssl/openssl] 56aee7: read lock store on ossl_method_store_do_all

[Neil Horman]

  Branch: refs/heads/openssl-3.3
  Home:   https://github.com/openssl/openssl
  Commit: 56aee7cfaa46b2d465e2596a53b6e3c306f00356
      https://github.com/openssl/openssl/commit/56aee7cfaa46b2d465e2596a53b6e3c306f00356
  Author: Neil Horman <nhorman at openssl.org>
  Date:   2024-07-09 (Tue, 09 Jul 2024)

  Changed paths:
    M crypto/property/property.c

  Log Message:
  -----------
  read lock store on ossl_method_store_do_all

Theres a data race between ossl_method_store_insert and
ossl_method_store_do_all, as the latter doesn't take the property lock
before iterating.

However, we can't lock in do_all, as the call stack in several cases
later attempts to take the write lock.

The choices to fix it are I think:
1) add an argument to indicate to ossl_method_store_do_all weather to
   take the read or write lock when doing iterations, and add an
   is_locked api to the ossl_property_[read|write] lock family so that
   subsequent callers can determine if they need to take a lock or not

2) Clone the algs sparse array in ossl_method_store_do_all and use the
   clone to iterate with no lock held, ensuring that updates to the
   parent copy of the sparse array are left untoucheTheres a data race
   between ossl_method_store_insert and ossl_method_store_do_all, as the
   latter doesn't take the property lock before iterating.

I think method (2), while being a bit more expensive, is probably the
far less invasive way to go here

Fixes #24672

Reviewed-by: Paul Dale <ppzgs1 at gmail.com>
Reviewed-by: Matt Caswell <matt at openssl.org>
Reviewed-by: Tomas Mraz <tomas at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24782)

(cherry picked from commit d8def79838cd0d5e7c21d217aa26edb5229f0ab4)



To unsubscribe from these emails, change your notification settings at https://github.com/openssl/openssl/settings/notifications