[openssl/openssl] e1b32a: convert ossl method store cache to do full prop_qu...

"'Neil Horman' via openssl-commits" <[email protected]>
Newsgroups gmane.comp.encryption.openssl.cvs
Message-ID <openssl/openssl/push/refs/heads/master/[email protected]>
  Branch: refs/heads/master
  Home:   https://github.com/openssl/openssl
  Commit: e1b32a0201db19a302fc1e7ed91081794bf968d4
      https://github.com/openssl/openssl/commit/e1b32a0201db19a302fc1e7ed91081794bf968d4
  Author: Neil Horman <[email protected]>
  Date:   2026-06-17 (Wed, 17 Jun 2026)

  Changed paths:
    M crypto/property/property.c

  Log Message:
  -----------
  convert ossl method store cache to do full prop_query comparison

As noted in this conversation:
https://github.com/openssl/openssl/pull/31018#discussion_r3386478127

While unlikely, it is possible that a single provider may provide an
algorithm for the same <name,operation_id,provider> tuple, differing
only by property query string.  If, somehow the property strings for
those two algorithms hash to the same value, the property cache may
return the wrong algorithm.

This was mitigated prior to the introduction of the atomic link list
implementation by having the internal hash table do a collision check,
in which the full property string (along with the nid and provider
pointer) were compared byte-for-byte.

Fix this by re-introducing the same comparison.  We already do a
comparison check on the exact nid value and provider pointer, so we now
store the property query for each QUERY and compare it to the query
string requsted using strcmp.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Wed Jun 17 14:38:39 2026
(Merged from https://github.com/openssl/openssl/pull/31487)


  Commit: 1a564e530b7e92acf8dbc58c5b5ca7a1cc98d5ed
      https://github.com/openssl/openssl/commit/1a564e530b7e92acf8dbc58c5b5ca7a1cc98d5ed
  Author: Neil Horman <[email protected]>
  Date:   2026-06-17 (Wed, 17 Jun 2026)

  Changed paths:
    M crypto/property/property.c

  Log Message:
  -----------
  make ossl_method_store use cmp_exch_ptr when cleaning archive

from the conversation here:
https://github.com/openssl/openssl/pull/31018#discussion_r3386832056

@mattcaswell noted that while cleaning QUERY items and moving them to
the archive list, we do an atomic load of a QUERY's next pointer to
another shared query's next pointer.  While its not been observed, it
may be possible for the clean operation to move an element to the
archive while a concurrent thread is prepending to the list, the result
being that the active (cache_list) list has a head pointer whos next
pointer points into the archive list.

The result of this would be subsequent lookups fail to find anything not
archived in the cache, and need to go through the slow
ossl_method_construct path again to slowly rebuild the cache.  Thats not
catastrophic, but its definately a bug that will result in additional
memory allocations, along with entries that never get used again, and
possible memory leaks.

Switch the load_ptr call to be an atomic cmp_exch_ptr call to ensure
that the node being visited isn't mutated concurrently by both a thread
doing a clean and a list insert.  This ensures that only one thread wins
the update, while the other restarts their operation.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Wed Jun 17 14:38:41 2026
(Merged from https://github.com/openssl/openssl/pull/31487)


  Commit: 43e1e98a26510e676ea27c0039c679a544c48d89
      https://github.com/openssl/openssl/commit/43e1e98a26510e676ea27c0039c679a544c48d89
  Author: Neil Horman <[email protected]>
  Date:   2026-06-17 (Wed, 17 Jun 2026)

  Changed paths:
    M crypto/property/property.c
    M test/property_test.c

  Log Message:
  -----------
  restore "oldest wins" behavior in method store

We expressly define EVP_*fetch apis as not guaranteeing which provider
and algorithm is sourced from.  However, its likely that some users have
some inadvertent reliance on getting the same provider for a non
provider specific (and non property specific) fetch.  While thats
generally bad practice (since we don't guarantee it), its particularly
hard to provide that behavior in the new cache infrastructure, so lets
save everyone some trouble by not changing that behavior needlessly.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Wed Jun 17 14:38:43 2026
(Merged from https://github.com/openssl/openssl/pull/31487)


Compare: https://github.com/openssl/openssl/compare/f3f163243a4f...43e1e98a2651

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

-- 
You received this message because you are subscribed to the Google Groups "openssl-commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-commits/openssl/openssl/push/refs/heads/master/f3f163-43e1e9%40github.com.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.