summaryrefslogtreecommitdiffstats
path: root/crypto/evp
diff options
context:
space:
mode:
authorNeil Horman <nhorman@openssl.org>2023-12-20 16:01:17 +0100
committerNeil Horman <nhorman@openssl.org>2024-01-01 18:57:59 +0100
commit94be985cbcc1f0a5cf4f172d4a8d06c5c623122b (patch)
treeeb8dfddae26d9a2ad0bad7e66508a4d17b18de14 /crypto/evp
parentapps: Don't print hostname on bio_out during connect. (diff)
downloadopenssl-94be985cbcc1f0a5cf4f172d4a8d06c5c623122b.tar.xz
openssl-94be985cbcc1f0a5cf4f172d4a8d06c5c623122b.zip
gate calling of evp_method_id on having a non-zero name id
If a name is passed to EVP_<OBJ>_fetch of the form: name1:name2:name3 The names are parsed on the separator ':' and added to the store, but during the lookup in inner_evp_generic_fetch, the subsequent search of the store uses the full name1:name2:name3 string, which fails lookup, and causes subsequent assertion failures in evp_method_id. instead catch the failure in inner_evp_generic_fetch and return an error code if the name_id against a colon separated list of names fails. This provides a graceful error return path without asserts, and leaves room for a future feature in which such formatted names can be parsed and searched for iteratively Add a simple test to verify that providing a colon separated name results in an error indicating an invalid lookup. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> (Merged from https://github.com/openssl/openssl/pull/23110)
Diffstat (limited to 'crypto/evp')
-rw-r--r--crypto/evp/evp_fetch.c21
1 files changed, 17 insertions, 4 deletions
diff --git a/crypto/evp/evp_fetch.c b/crypto/evp/evp_fetch.c
index c643ae8f9a..bd816be5f4 100644
--- a/crypto/evp/evp_fetch.c
+++ b/crypto/evp/evp_fetch.c
@@ -318,13 +318,26 @@ inner_evp_generic_fetch(struct evp_method_data_st *methdata,
* there is a correct name_id and meth_id, since those have
* already been calculated in get_evp_method_from_store() and
* put_evp_method_in_store() above.
+ * Note that there is a corner case here, in which, if a user
+ * passes a name of the form name1:name2:..., then the construction
+ * will create a method against all names, but the lookup will fail
+ * as ossl_namemap_name2num treats the name string as a single name
+ * rather than introducing new features where in the EVP_<obj>_fetch
+ * parses the string and querys for each, return an error.
*/
if (name_id == 0)
name_id = ossl_namemap_name2num(namemap, name);
- meth_id = evp_method_id(name_id, operation_id);
- if (name_id != 0)
- ossl_method_store_cache_set(store, prov, meth_id, propq,
- method, up_ref_method, free_method);
+ if (name_id == 0) {
+ ERR_raise_data(ERR_LIB_EVP, ERR_R_FETCH_FAILED,
+ "Algorithm %s cannot be found", name);
+ free_method(method);
+ method = NULL;
+ } else {
+ meth_id = evp_method_id(name_id, operation_id);
+ if (name_id != 0)
+ ossl_method_store_cache_set(store, prov, meth_id, propq,
+ method, up_ref_method, free_method);
+ }
}
/*