Make sure we free process_data_dest if it is not actually used.
Found by the reproducible error patch in #21668
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21741)
issue: https://github.com/openssl/openssl/issues/21718
build break reported:
crypto/threads_pthread.c:76:5: warning: implicit declaration of function 'pthread_mutexattr_settype'; did you mean 'pthread_mutexattr_destroy'? [-Wimplicit-function-declaration]
76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| pthread_mutexattr_destroy
crypto/threads_pthread.c:76:38: error: 'PTHREAD_MUTEX_NORMAL' undeclared (first use in this function); did you mean 'PTHREAD_MUTEX_TIMED_NP'?
76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
| ^~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_TIMED_NP
This occurs because PTHREAD_MUTEX_NORMAL is only defined in glibc if
__USE_UNIX98 or __USE_XOPEN2K8 is defined, which is derived from setting
__USE_POSIX_C_SOURCE or __XOPEN_SOURCE is selected in the glibc feature
set for a build. Since openssl selects no specific feature set from
glibc, the build break occurs
We could select a feature set of course, but that seems like a
significant discussion to have prior to doing so. Instead, the simpler
solution is to just not set the mutex type at all, given that
pthread_mutexattr_init sets the default mutex type, which should be akin
to normal anyway (i.e. no mutex error checking or allowed-recursive
behavior)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21726)
Fixes#21198
decoder objects were setting propq as NULL.
Added a set_ctx/settable_ctx to all decoders that should supply
a property query parameter to internal functions.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21219)
Found via the reproducible error injection in #21668
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21723)
The routines declared in there are entirely libcrypto internal, so
include/crypto/decoder.h is better suited for them.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/21733)
bn_wexpand can fail as the result of a memory allocation failure. We
should not be calling ossl_assert() on its result because it can fail in
normal operation.
Found via the reproducible error injection in #21668
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/21725)
A recursive OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS) call
may happen if an out-of-memory error happens at the first callstack,
and the dead-lock happens at the second callstack, because ossl_err_get_state_int
calls OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS) although that
call is currently already executing.
At least on posix system this causes the process to freeze at this
point, and must be avoided whatever it takes.
The fix is using err_shelve_state around the critical region, which
makes ossl_err_get_state_int return early and not call the recursive
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS).
This can be reproduced with my error injection patch.
The test vector has been validated on the master branch:
$ ERROR_INJECT=1692279870 ../util/shlib_wrap.sh ./asn1parse-test ./corpora/asn1parse/027f6e82ba01d9db9a9167b83e56cc9f2c602550
ERROR_INJECT=1692279870
#0 0x7f280b42fef8 in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cpp:86
#1 0x5610a3f396b4 in my_malloc fuzz/test-corpus.c:114
#2 0x7f280a2eb94c in CRYPTO_malloc crypto/mem.c:177
#3 0x7f280a2dafdb in OPENSSL_LH_insert crypto/lhash/lhash.c:114
#4 0x7f280a1c87fe in err_load_strings crypto/err/err.c:264
#5 0x7f280a1c87fe in err_load_strings crypto/err/err.c:259
#6 0x7f280a1c87fe in ERR_load_strings_const crypto/err/err.c:301
#7 0x7f280a6f513b in ossl_err_load_PROV_strings providers/common/provider_err.c:233
#8 0x7f280a1cf015 in ossl_err_load_crypto_strings crypto/err/err_all.c:109
#9 0x7f280a2e9b8c in ossl_init_load_crypto_strings crypto/init.c:190
#10 0x7f280a2e9b8c in ossl_init_load_crypto_strings_ossl_ crypto/init.c:181
#11 0x7f2808cfbf67 (/lib/x86_64-linux-gnu/libc.so.6+0x99f67)
#12 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#13 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#14 0x5610a3f38e2f in FuzzerInitialize fuzz/asn1parse.c:29
#15 0x5610a3f38783 in main fuzz/test-corpus.c:194
#16 0x7f2808c8bd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#17 0x7f2808c8be3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#18 0x5610a3f38d34 in _start (/home/runner/work/openssl/openssl/fuzz/asn1parse-test+0x3d34)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==27629==ERROR: AddressSanitizer: ABRT on unknown address 0x03e900006e23 (pc 0x7f2808cfbef8 bp 0x7f280b36afe0 sp 0x7ffd545b2460 T0)
#0 0x7f2808cfbef8 (/lib/x86_64-linux-gnu/libc.so.6+0x99ef8)
#1 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#2 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#3 0x7f280a1c935e in ossl_err_get_state_int crypto/err/err.c:705
#4 0x7f280a1cf1f9 in ERR_new crypto/err/err_blocks.c:20
#5 0x7f280a2eb9ac in CRYPTO_malloc crypto/mem.c:205
#6 0x7f280a2dafdb in OPENSSL_LH_insert crypto/lhash/lhash.c:114
#7 0x7f280a1c87fe in err_load_strings crypto/err/err.c:264
#8 0x7f280a1c87fe in err_load_strings crypto/err/err.c:259
#9 0x7f280a1c87fe in ERR_load_strings_const crypto/err/err.c:301
#10 0x7f280a6f513b in ossl_err_load_PROV_strings providers/common/provider_err.c:233
#11 0x7f280a1cf015 in ossl_err_load_crypto_strings crypto/err/err_all.c:109
#12 0x7f280a2e9b8c in ossl_init_load_crypto_strings crypto/init.c:190
#13 0x7f280a2e9b8c in ossl_init_load_crypto_strings_ossl_ crypto/init.c:181
#14 0x7f2808cfbf67 (/lib/x86_64-linux-gnu/libc.so.6+0x99f67)
#15 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#16 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#17 0x5610a3f38e2f in FuzzerInitialize fuzz/asn1parse.c:29
#18 0x5610a3f38783 in main fuzz/test-corpus.c:194
#19 0x7f2808c8bd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#20 0x7f2808c8be3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#21 0x5610a3f38d34 in _start (/home/runner/work/openssl/openssl/fuzz/asn1parse-test+0x3d34)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x99ef8)
==27629==ABORTING
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21683)
CLA: trivial
Reviewed-by: Paul Dale <pauli@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/21692)
This happens if this function is called for signed content.
Added ossl_cms_env_enc_content_free() for cleaning enveloped content.
Fixed indentation in ossl_cms_env_enc_content_free
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21676)
This fixes the reported crashes 32-bit HPUX systems due to
raw out and inp pointer values, and adds one nop instruction
on 64-bit systems, like it is done in other assembly modules
for those systems.
The fix was tested by @johnkohl-hcl see:
https://github.com/openssl/openssl/issues/17067#issuecomment-1668468033Fixes#17067
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21681)
When $label == "0", $label is not truthy, so `if ($label)` thinks there isn't
a label. Correct this by looking at the result of the s/// command.
Verified that there are no changes in the .S files created during a normal
build, and that the "0:" labels appear in the translation given in the error
report (and they are the only difference in the before and after output).
Fixes#21647
Change-Id: I5f2440100c62360bf4bdb7c7ece8dddd32553c79
Reviewed-by: Paul Dale <pauli@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/21653)
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21587)
Co-authored-by: suikammd <suikalala@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21298)
Add an assembly implementation of felem_{square,mul}, which will be
implemented whenever Altivec support is present and the core implements
ISA 3.0 (Power 9) or greater.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
Adopt a 56-bit redundant-limb Solinas' reduction approach for efficient
modular multiplication in P384. This has the affect of accelerating
digital signing by 446% and verification by 106%. The implementation
strategy and names of methods are the same as that provided in
ecp_nistp224 and ecp_nistp521.
As in Commit 1036749883 ("ec: Add run time code selection for p521
field operations"), allow for run time selection of implementation for
felem_{square,mul}, where an assembly implementation is proclaimed to
be present when ECP_NISTP384_ASM is present.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
Runtime selection of implementations for felem_{square,mul} depends on
felem_{square,mul}_wrapper functions, which overwrite function points in
a similar design to that of .plt.got sections used by program loaders
during dynamic linking.
There's no reason why these functions need to have external linkage.
Mark static.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
When decoding 0 as the selection means to decode anything
you get.
However when exporting and then importing the key data 0 as
selection is not meaningful.
So we set it to OSSL_KEYMGMT_SELECT_ALL to make the export/import
function export/import everything that we have decoded.
Fixes#21493
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21519)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21579)
The PEM_read_bio_Parameters[_ex] function does not have the capability
of specifying a password callback. We should not use the fallback password
callback in this case because it will attempt to send a prompt for the
password which might not be the correct thing to do. We should just not
use a password in that case.
Fixes#21588
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
We're always supposed to add the fallback "unsupported" error if we don't
have anything better. However in some cases this wasn't happening because
we were incorrectly setting "flag_construct_called" - even though the
construct function had failed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
In the definition of the latest revised LoongArch64 vector instruction manual,
it is clearly pointed out that the undefined upper three bits of each byte in
the control register of the vshuf.b instruction should not be used, otherwise
uncertain results may be obtained. Therefore, it is necessary to correct the
use of the vshuf.b instruction in the existing vpaes-loongarch64.pl code to
avoid erroneous calculation results in future LoongArch64 processors.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21530)
Also fixes a similar regression in X509_VERIFY_PARAM_add0_table().
Commit 38ebfc3 introduced a regression in 3.0.6 that changed the return
value of the two functions above from 1 on success to the number of entries
in the stack. If there are more than one entry then this is a change in
behaviour which should not have been introduced into a stable release.
This reverts the behaviour back to what it was prior to the change. The code
is slightly different to the original code in that we also handle a possible
-1 return value from the stack push function. This should never happen in
reality because we never pass a NULL stack as a parameter - but for the sake
of robustness we handle it anyway.
Note that the changed behaviour exists in all versions of 3.1 (it never had
the original version). But 3.1 should be fully backwards compatible with 3.0
so we should change it there too.
Fixes#21570
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21576)
Running LSX instructions requires both the hardware support and the
kernel support. The `cpucfg` instruction only tests the hardware
support, causing a SIGILL if the hardware supports LSX but the kernel
does not.
Use `getauxval(AT_HWCAP)` as the ["Software Development and Build
Convention for LoongArch Architectures"][1] manual suggests.
The LOONGARCH_HWCAP_LSX and LOONGARCH_HWCAP_LASX bits are copied from
the manual too. In Glibc 2.38 they'll be provided by <sys/auxv.h> as
well, but they are unavailable in earlier Glibc versions so we cannot
rely on it.
The getauxval syscall and Glibc wrapper are available since day one
(Linux-5.19 and Glibc-2.36) for LoongArch.
Fixes#21508.
[1]:https://github.com/loongson/la-softdev-convention/blob/master/la-softdev-convention.adoc#kernel-constraints
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21509)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21545)
If |q| >= |p| then the q value is obviously wrong as q
is supposed to be a prime divisor of p-1.
We check if p is overly large so this added test implies that
q is not large either when performing subsequent tests using that
q value.
Otherwise if it is too large these additional checks of the q value
such as the primality test can then trigger DoS by doing overly long
computations.
Fixes CVE-2023-3817
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21550)
The pre-existing error cases where DH_check returned zero
are not related to the dh params in any way, but are only
triggered by out-of-memory errors, therefore having *ret
set to zero feels right, but since the new error case is
triggered by too large p values that is something different.
On the other hand some callers of this function might not
be prepared to handle the return value correctly but only
rely on *ret. Therefore we set some error bits in *ret as
additional safety measure.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21524)
Reviewed-by: Paul Dale <pauli@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/21515)
CLA: trivial
The purpose of adding the conditional operator on line 710 is to check
if the value of the variable 'fplace' exceeds the size of the array
'fconvert', and to reduce the value of 'fplace' by 1, so that later on
we can set the value to zero of the array element with the index 'fplace'
and not make any calls beyond the array edges.
However, the condition on line 710 will always be false, because
the size of 'fconvert' is strictly specified at the beginning of
the 'fmtfp()' function (line 571), so it is reasonable to remove
this conditional operator, as well as the unreachable decrementation
code of the variable 'fplace'.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21325)
Function `X509at_add1_attr()` (crypto/x509/x509_att.c) rejects to add a duplicity into `*x` but it searches in a wrong stack.
Changed to search in `*x`.
CLA: trivial
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21505)
The hardware-assisted ARMv8.2 implementation is already in keccak1600-armv8.pl.
It is not called because the author mentioned that it's not actually obvious
that it will provide performance improvements. The test on Apple M1 Firestorm
shows that the ARMv8.2 implementation could improve about 36% for large blocks.
So let's enable ARMv8.2 accelerated SHA3 on Apple CPU family.
Fixes#21380
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21398)
The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.
There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.
An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.
The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().
CVE-2023-3446
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
QUIC error code, frame type and reason is in error data
Fixes#21337
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21476)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21467)
Signed-off-by: lan1120 <lanming@huawei.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21170)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21135)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21401)
The most expensive part of using a PKEY decoder is the
OSSL_DECODER_CTX_new_for_pkey() call. This builds up all of the decoder
chains, which is a complex and time consuming operation. However, if no
new providers have been loaded/unloaded since the last time it was called
we can expect the same results for the same parameters. Note that this
operation takes place *before* we event parse the data for decoding so it
is not dependent on the parsed data at all.
We introduce a cache for OSSL_DECODER_CTX objects. If we have been called
with the same parameters then we just duplicate an existing
OSSL_DECODER_CTX. This should be significantly faster than creating a new
one every time.
Partially addressed the issue in #15199
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21426)
This change is intended to provide some safety for uninitialized stack failures
that have appeared in 80-test_cmp_http on NonStop x86 when run in a complex
CI/CD Jenkins environment. This change also adds init_pint() to handle the
initialization of a pointer to int value.
Fixes: #21083
Signed-off-by: Randall S. Becker <randall.becker@nexbridge.ca>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21109)
(cherry picked from commit 45cd2554ef)
rhotates tables are placed to .text section which confuses tools such as BOLT.
Move them to rodata to unbreak and avoid polluting icache/iTLB with data.
CLA: trivial
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21440)
