lots of people may want to print params to a buffer. Make it part of
our api
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25630)
Adds trace messages for method store add/remove and fetch operations
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25630)
Adds tracing messages to the
init/teardown/gettable_params/get_params/query/unquery operations for a
provider
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25630)
param->ctrl translation: Fix fix_ecdh_cofactor()
In POST_PARAMS_TO_CTRL state the fix_ecdh_cofactor() function should
return value in ctx->p1
param->ctrl translation: fix evp_pkey_ctx_setget_params_to_ctrl
return
Since some of the ctrl operations may return 0 as valid value
(e.g. ecdh_cofactor value 0 is valid setting), before colling
POST_PARAMS_TO_CTRL, we need to check return value for 0 as well
otherwise the evp_pkey_ctx_setget_params_to_ctrl function fails
without a chance to fix the return value
param->ctrl translation: Set ecdh_cofactor default action_type GET
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22587)
Indent namingAuthority section with two spaces to match the parent
node.
Signed-off-by: oleg.hoefling <oleg.hoefling@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25814)
When sk_GENERAL_NAME_reserve() fails, ialt is not freed.
Add the freeing operation in the common error path.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25876)
There are several calls to sk_GENERAL_NAME_free() where the argument is
actually NULL, there are not necessary.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25877)
ctx->propq is a duplicated string, but the error code does not free
the duplicated string's memory. If e.g. EVP_CIPHER_fetch() fails then
we can leak the string's memory.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25812)
This at least fixes the build failures on AIX
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25704)
by fixing OSSL_trace_begin() to return NULL when given category is not enabled
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25652)
Probing for crypto cards during initialization by issuing an ioctl to the
zcrypt device driver can cause a lot of traffic and overhead, because it
runs for each and every application that uses OpenSSL, regardless if that
application will later perform ME or CRT operations or not.
Fix this by performing no probing during initialization, but detect the
crypto card availability only at the first ME/CRT operation that is subject
to be offloaded. If the ioctl returns ENODEV, then no suitable crypto
card is available in the system, and we disable further offloading
attempts by setting flag OPENSSL_s390xcex_nodev to 1.
Setting the global flag OPENSSL_s390xcex_nodev in case of ENODEV is
intentionally not made in a thread save manner, because the only thing
that could happen is that another thread, that misses the flag update,
also issues an ioctl and gets ENODEV as well.
The file descriptor is not closed in such error cases, because this could
cause raise conditions where we would close a foreign file if the same
file descriptor got reused by another thread. The file descriptor is finally
closed during termination by the atexit handler.
In case the ioctl returns ENOTTY then this indicates that the file descriptor
was closed (e.g. by a sandbox), but in the meantime the same file descriptor
has been reused for another file. Do not use the file descriptor anymore,
and also do not close it during termination.
Fixes: 79040cf29e
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25576)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22575)
There was an API change done as part of PR #24450.
This patch reverts it.
Fixes#25690
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25692)
This information is already present as an 'openssl version' item.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25694)
If the application provides custom memory allocations functions via
CRYPTO_set_mem_functions() then those should be used instead something
else like posix_memalign(). The applications might verify alloc and free
calls and pointers from posix_memalign() were never returned by the
implementations.
At least stunnel4 complains here.
Use posix_memalign() or if aligned_alloc() only if the application did
not provide a custom malloc() implementation. In case of a custom
implementation use CRYPTO_malloc() and align the memory accordingly.
Fixes#25678
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25682)
The BN_GF2m_poly2arr() function converts characteristic-2 field
(GF_{2^m}) Galois polynomials from a representation as a BIGNUM bitmask,
to a compact array with just the exponents of the non-zero terms.
These polynomials are then used in BN_GF2m_mod_arr() to perform modular
reduction. A precondition of calling BN_GF2m_mod_arr() is that the
polynomial must have a non-zero constant term (i.e. the array has `0` as
its final element).
Internally, callers of BN_GF2m_poly2arr() did not verify that
precondition, and binary EC curve parameters with an invalid polynomial
could lead to out of bounds memory reads and writes in BN_GF2m_mod_arr().
The precondition is always true for polynomials that arise from the
standard form of EC parameters for characteristic-two fields (X9.62).
See the "Finite Field Identification" section of:
https://www.itu.int/ITU-T/formal-language/itu-t/x/x894/2018-cor1/ANSI-X9-62.html
The OpenSSL GF(2^m) code supports only the trinomial and pentanomial
basis X9.62 forms.
This commit updates BN_GF2m_poly2arr() to return `0` (failure) when
the constant term is zero (i.e. the input bitmask BIGNUM is not odd).
Additionally, the return value is made unambiguous when there is not
enough space to also pad the array with a final `-1` sentinel value.
The return value is now always the number of elements (including the
final `-1`) that would be filled when the output array is sufficiently
large. Previously the same count was returned both when the array has
just enough room for the final `-1` and when it had only enough space
for non-sentinel values.
Finally, BN_GF2m_poly2arr() is updated to reject polynomials whose
degree exceeds `OPENSSL_ECC_MAX_FIELD_BITS`, this guards against
CPU exhausition attacks via excessively large inputs.
The above issues do not arise in processing X.509 certificates. These
generally have EC keys from "named curves", and RFC5840 (Section 2.1.1)
disallows explicit EC parameters. The TLS code in OpenSSL enforces this
constraint only after the certificate is decoded, but, even if explicit
parameters are specified, they are in X9.62 form, which cannot represent
problem values as noted above.
Initially reported as oss-fuzz issue 71623.
A closely related issue was earlier reported in
<https://github.com/openssl/openssl/issues/19826>.
Severity: Low, CVE-2024-9143
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25639)
If SRP_user_pwd_set1_ids() fails during one of the duplications, or id
is NULL, then the old pointer values are still stored but they are now dangling.
Later when SRP_user_pwd_free() is called these are freed again,
leading to a double free.
Although there are no such uses in OpenSSL as far as I found,
it's still a public API.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25655)
fix https://github.com/openssl/openssl/issues/25112
As defined in the C standard:
In all cases the argument is an int, the value of which shall
be representable as an unsigned char or shall equal the value
of the macro EOF. If the argument has any other value, the
behavior is undefined.
This is because they're designed to work with the int values returned
by getc or fgetc; they need extra work to handle a char value.
If EOF is -1 (as it almost always is), with 8-bit bytes, the allowed
inputs to the ctype.h functions are:
{-1, 0, 1, 2, 3, ..., 255}.
However, on platforms where char is signed, such as x86 with the
usual ABI, code like
char *p = ...;
... isspace(*p) ...
may pass in values in the range:
{-128, -127, -126, ..., -2, -1, 0, 1, ..., 127}.
This has two problems:
1. Inputs in the set {-128, -127, -126, ..., -2} are forbidden.
2. The non-EOF byte 0xff is conflated with the value EOF = -1, so
even though the input is not forbidden, it may give the wrong
answer.
Casting char inputs to unsigned char first works around this, by
mapping the (non-EOF character) range {-128, -127, ..., -1} to {128,
129, ..., 255}, leaving no collisions with EOF. So the above
fragment needs to be:
char *p = ...;
... isspace((unsigned char)*p) ...
This patch inserts unsigned char casts where necessary. Most of the
cases I changed, I compile-tested using -Wchar-subscripts -Werror on
NetBSD, which defines the ctype.h functions as macros so that they
trigger the warning when the argument has type char. The exceptions
are under #ifdef __VMS or #ifdef _WIN32. I left alone calls where
the input is int where the cast would obviously be wrong; and I left
alone calls where the input is already unsigned char so the cast is
unnecessary.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25113)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25608)
If sk_ASN1_UTF8STRING_push() fails then the duplicated string will leak
memory. Add a ASN1_UTF8STRING_free() to fix this.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25604)
Fixes#25594
The code jumps to an error block when EVP_VerifyUpdate fails.
This error block does not free abuf.
In the success path the abuf memory is freed.
Move the free operation to the error block.
CLA: trivial
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25596)
PRF in PBKDF2-params is optional and defaults to hmacWithSHA1.
CLA: trivial
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25568)
provider.
Revert changes to m_sigver.c related to #ifdef FIPS_MODULE and exclude
the file using build.info instead.
Also exclude these calls inside EVP_DigestUpdate() within the FIPS
provider since this API should only be used for self testing digests.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25570)
The arguments of the `nc_match_single` function have different names
in the declaration and definition or are mixed up in places.
CLA: trivial
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25592)
Use non-usual params of pkcs11 module will trigger a null ptr deref bug. Fix it for #25493
CLA: trivial
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25496)
Force the use of the derivation function when creating OpenSSL's internal
DRBGs.
FIPS mandates the use of a derivation function, so 3.4 cannot be validated as
it stands which run counter to the indicator work that was included.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@devever.net>
(Merged from https://github.com/openssl/openssl/pull/25511)
(cherry picked from commit 0ab796ef96)
issuer passed as second parameter to check_issued may result in
NULL dereference
CLA: trivial
Reviewed-by: Hugo Landau <hlandau@devever.net>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24760)
Some of the BE specific permutes were incorrect. Fix them.
This passes all tests on a P10/ppc64 debian unstable host.
Fixes#25451
CLA: trivial
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25483)
For FIPS 140-3 the continuous tests specified in SP 800-90B need to be
included on the output of any entropy source.
They are implemented here as a replacement for the primary DRBG in the FIPS
provider. This results in a setup that looks like this:
+-------------+
| |
| Seed Source |
| |
+------+------+
|
|
v
+-------------+
| |
| CRNG Test |
| |
++----------+-+
| |
| |
v v
+--------------+ +--------------+
| | | |
| Public DRBG | | Private DRBG |
| | | |
+--------------+ +--------------+
An additional benefit, that of avoiding DRBG chains, is also gained.
The current standards do not permit the output of one DRBG to be used
as the input for a second (i.e. a chain).
This also leaves open the future possibility of incorporating a seed
source inside the FIPS boundary.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25415)
The EVP_PKEY_Q_keygen function contains a list of algorithm type names
and fails if the requested name is not in the list. This prevents the use
of this function for externally supplied key type names.
We should just assume that any unrecognised key type name does not require
a parameter.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/25468)
