[pull] master from openssl:master#3
Merged
Conversation
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
We retain a numwpipes for now in the old record layer structure for use by DTLS. This will eventually be removed when DTLS moves over to the new way of doing things. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
This calculation is based on lots of information from state machine and elsewhere that the record layer cannot access. In reality it is sufficient to simply tell the record layer what version to use. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Now that we are no longer recursively addinng the prefix record this doesn't seem necessary any more. We always add it every time we do tls_write_records. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
This flag can now be managed entirely by the new record layer code so we move it into ossl_record_layer_st. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
In all cases we should be able to replace this with a simple check against rl->version. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
We wrap the callback and pass it to the record layer via the dispatch array, in order to avoid accessing it directly via SSL_CONNECTION. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Previously we were referencing the block_padding value through the SSL_CONNECTION. Now it is held within OSSL_RECORD_LAYER. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
There were a small number of references to the SSL_CONNECTION that can be removed easily and replaced with record layer equivalents. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
This also means we can convert SSLfatal calls to RLAYERfatal Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
We use the returned data to decide how to split the data we want to write into records. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Move the multiblock code into a separate file and introduce the usage of record_functions_st for some write functions. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Make sure we free the record layer before we free the connection BIOs Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #19198)
Also add internal functionality to get a QUIC_CONNECTION pointer from an SSL pointer, and setters / getters for the GQX and ACKM fields. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18838)
Implements the design doc/designs/quic-design/rx-depacketizer.md. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18838)
…e valid in Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18838)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18838)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18838)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #19025)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from #19257)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19040)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19275)
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19275)
The IKM was not respected by the s390x specific implementations of X25519 and X448 keygen. This caused test failures and wrong results if the PCC instruction was actually available and supported X25519 and/or X448. Fixes: 78c44b0 ("Add HPKE DHKEM provider support for EC, X25519 and X448.") Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19278)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from #19510)
In the ideal scenario, performance can reach up to 2.2X. But in single block input or CFB/OFB mode, CBC encryption, performance could drop about 50%. Perf data on Kunpeng-920 2.6GHz hardware, before and after optimization: Before: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes SM4-CTR 75318.96k 79089.62k 79736.15k 79934.12k 80325.44k 80068.61k SM4-ECB 80211.39k 84998.36k 86472.28k 87024.93k 87144.80k 86862.51k SM4-GCM 72156.19k 82012.08k 83848.02k 84322.65k 85103.65k 84896.43k SM4-CBC 77956.13k 80638.81k 81976.17k 81606.31k 82078.91k 81750.70k SM4-CFB 78078.20k 81054.87k 81841.07k 82396.38k 82203.99k 82236.76k SM4-OFB 78282.76k 82074.03k 82765.74k 82989.06k 83200.68k 83487.17k After: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes SM4-CTR 35678.07k 120687.25k 176632.27k 177192.62k 177586.18k 178295.18k SM4-ECB 35540.32k 122628.07k 175067.90k 178007.84k 178298.88k 178328.92k SM4-GCM 34215.75k 116720.50k 170275.16k 171770.88k 172714.21k 172272.30k SM4-CBC 35645.60k 36544.86k 36515.50k 36732.15k 36618.24k 36629.16k SM4-CFB 35528.14k 35690.99k 35954.86k 35843.42k 35809.18k 35809.96k SM4-OFB 35563.55k 35853.56k 35963.05k 36203.52k 36233.85k 36307.82k Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com> Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #19547)
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #19526)
For some reason the newly introduced CI test for sctp causes issues. It is unknown why this seems to work when testing, but doesnt work once it was merged. The test has been put into its own file, with skips on error if the setup fails.. This will need to be merged to test if this works. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19511)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19429)
TLS pipelining provides the ability for libssl to read or write multiple records in parallel. It requires special ciphers to do this, and there are currently no built-in ciphers that provide this capability. However, the dasync engine does have such a cipher, so we add a test for this capability using that engine. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19456)
…lled The pipeline input/output buf arrays must remain accessible to the EVP_CIPHER_CTX until EVP_Cipher is subsequently called. This fixes an asan error discovered by the newly added pipeline test. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19456)
During read pipelining we must ensure that the buffer is sufficiently large to read enough data to fill our pipelines. We also remove some code that moved data to the start of the packet if we can. This was unnecessary because of later code which would end up moving it anyway. The earlier move was also incorrect in the case that |clearold| was 0. This would cause the read pipelining code to fail with sufficiently large records. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19456)
Document the effect on the internal read buffer when using pipelining. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19456)
These functions pass a library content and prop query. The i2d documentation related to these functions has been corrected since the bio and fp functions always return 0 or 1. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18427)
i2d_XXX_bio and i2d_XXX_fp return either 0 or 1. Other i2d_XXX functions return the number of bytes or negative on error. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #18427)
|uclen| is created from three byte values, so this seems a bit redundant, but if it makes coverity happy Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19519)
Not possible to hit but good to address. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19576)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #19581)
NOTE: Not Configurations/unix-Makefile.tmpl, as that was done 4 years ago, in commit a23f031. So far assembly modules were intended to be built as .pl->.S->.{asmext} followed by .{asmext}->.o. This posed a problem in build_all_generated rule if it was executed on another computer, and also turned out to be buggy, as .S was also translated to .{asmext} on Windows and VMS. Both issues are fixed by changing the rule sequence to .pl->.S and then .S->.s->.o, with the added benefit that the Windows and VMS build file templates are more in sync with unix-Makefile.tmpl and slightly simpler. Fixes #19594 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19598)
…nore case The use case is that uppercase .ASM extension may be used on some platforms, and we were only testing for the lowercase extension. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #19604)
Stitched ciphersuites can grow by more during encryption than the code allowed for. We fix the calculation and add an assert to check we go it right. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from #19516)
We fix dtls_get_max_record_overhead() to give a better value for the max record overhead. We can't realistically handle the compression case so we just ignore that. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from #19516)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from #19516)
pull Bot
pushed a commit
that referenced
this pull request
Sep 1, 2023
When running test_quicapi on master on a Fedora 38 with santizier, a stack
use-after-free is reported:
```
75-test_quicapi.t ..
=================================================================
==28379==ERROR: AddressSanitizer: stack-use-after-return on address 0x03ffa22a2961 at pc 0x03ffa507384a bp 0x03fffb576d68 sp 0x03fffb576550
READ of size 8 at 0x03ffa22a2961 thread T0
#0 0x3ffa5073849 in memcpy (/usr/lib64/libasan.so.8+0x73849) (BuildId: ce24d4ce2e06892c2e9105155979b957089a182c)
#1 0x118b883 in tls_handle_alpn ssl/statem/statem_srvr.c:2221
#2 0x111569d in tls_parse_all_extensions ssl/statem/extensions.c:813
#3 0x118e2bf in tls_early_post_process_client_hello ssl/statem/statem_srvr.c:1957
#4 0x118e2bf in tls_post_process_client_hello ssl/statem/statem_srvr.c:2290
#5 0x113d797 in read_state_machine ssl/statem/statem.c:712
#6 0x113d797 in state_machine ssl/statem/statem.c:478
#7 0x10729f3 in SSL_do_handshake ssl/ssl_lib.c:4669
#8 0x11cec2d in ossl_quic_tls_tick ssl/quic/quic_tls.c:717
#9 0x11afb03 in ch_tick ssl/quic/quic_channel.c:1296
#10 0x10cd1a9 in ossl_quic_reactor_tick ssl/quic/quic_reactor.c:79
#11 0x10d948b in ossl_quic_tserver_tick ssl/quic/quic_tserver.c:160
#12 0x1021ead in qtest_create_quic_connection test/helpers/quictestlib.c:273
#13 0x102b81d in test_quic_write_read test/quicapitest.c:54
#14 0x12035a9 in run_tests test/testutil/driver.c:370
#15 0x1013203 in main test/testutil/main.c:30
#16 0x3ffa463262b in __libc_start_call_main (/usr/lib64/libc.so.6+0x3262b) (BuildId: 6bd4a775904d85009582d6887da4767128897d0e)
#17 0x3ffa463272d in __libc_start_main_impl (/usr/lib64/libc.so.6+0x3272d) (BuildId: 6bd4a775904d85009582d6887da4767128897d0e)
#18 0x101efb9 (/root/openssl/test/quicapitest+0x101efb9) (BuildId: 075e387adf6d0032320aaa18061f13e9565ab481)
Address 0x03ffa22a2961 is located in stack of thread T0 at offset 33 in frame
#0 0x10d868f in alpn_select_cb ssl/quic/quic_tserver.c:49
This frame has 1 object(s):
[32, 41) 'alpn' (line 50) <== Memory access at offset 33 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return (/usr/lib64/libasan.so.8+0x73849) (BuildId: ce24d4ce2e06892c2e9105155979b957089a182c) in memcpy
Shadow bytes around the buggy address:
0x03ffa22a2680: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2700: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2780: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2800: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2880: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
=>0x03ffa22a2900: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5[f5]f5 f5 f5
0x03ffa22a2980: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2a00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2a80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2b00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0x03ffa22a2b80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==28379==ABORTING
../../util/wrap.pl ../../test/quicapitest default ../../test/default.cnf ../../test/certs => 1
not ok 1 - running quicapitest
```
Fix this be making the protocols to select static constants and thereby moving
them out of the stack frame of the callback function.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from openssl#20904)
pull Bot
pushed a commit
that referenced
this pull request
Sep 1, 2023
…STRINGS)
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 openssl#21683)
pull Bot
pushed a commit
that referenced
this pull request
Aug 9, 2025
The new malloc failure test caught an asan error in this code: Direct leak of 40 byte(s) in 1 object(s) allocated from: 2025-08-07T03:22:20.3655117Z #0 0x7fb88d8fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 2025-08-07T03:22:20.3655796Z #1 0x5584f0e4670a in CRYPTO_malloc crypto/mem.c:211 2025-08-07T03:22:20.3656291Z #2 0x5584f0e4679d in CRYPTO_zalloc crypto/mem.c:231 2025-08-07T03:22:20.3657040Z #3 0x5584f11c4c10 in EVP_RAND_CTX_new crypto/evp/evp_rand.c:353 2025-08-07T03:22:20.3657656Z #4 0x5584f0e93b27 in rand_new_drbg crypto/rand/rand_lib.c:666 2025-08-07T03:22:20.3658289Z #5 0x5584f0e949d0 in rand_get0_public crypto/rand/rand_lib.c:843 2025-08-07T03:22:20.3658914Z #6 0x5584f0e9305b in RAND_bytes_ex crypto/rand/rand_lib.c:490 2025-08-07T03:22:20.3659486Z #7 0x5584f0b2405f in SSL_CTX_new_ex ssl/ssl_lib.c:4191 2025-08-07T03:22:20.3660183Z #8 0x5584f0ae313c in create_ssl_ctx_pair test/helpers/ssltestlib.c:958 2025-08-07T03:22:20.3660871Z #9 0x5584f0adeaf6 in do_handshake test/handshake-memfail.c:56 2025-08-07T03:22:20.3661539Z #10 0x5584f0adee50 in test_alloc_failures test/handshake-memfail.c:125 2025-08-07T03:22:20.3662161Z #11 0x5584f0cd9da8 in run_tests test/testutil/driver.c:342 2025-08-07T03:22:20.3662664Z #12 0x5584f0cda9e5 in main test/testutil/main.c:31 2025-08-07T03:22:20.3663450Z #13 0x7fb88d42a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f) 2025-08-07T03:22:20.3664630Z #14 0x7fb88d42a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f) 2025-08-07T03:22:20.3666608Z #15 0x5584f0ade864 in _start (/home/runner/work/openssl/openssl/test/handshake-memfail+0x22a864) (BuildId: 19659a44d8bed2c082918d25425f77e3a98df534) It occurs because when rand_get0_public/rand_get0_private sets an EVP_RAND_CTX object in its thread local storage, it neglects to check the return code of the operation, which may fail when the associated sparse array is expanded. fix it by checking the return code and failing the get0_[public|private] operation so the failure is graceful. Fixes openssl/project#1315 Reviewed-by: Paul Yang <paulyang.inf@gmail.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <ppzgs1@gmail.com> (Merged from openssl#28195)
pull Bot
pushed a commit
that referenced
this pull request
Jan 21, 2026
==1155903==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x5571e03fe712 in ASN1_get_object cmake-build-release-msan/./contrib/openssl/crypto/asn1/asn1_lib.c:62:11
#1 0x5571e0408981 in asn1_check_tlen cmake-build-release-msan/./contrib/openssl/crypto/asn1/tasn_dec.c:1164:13
#2 0x5571e04048c8 in asn1_item_embed_d2i cmake-build-release-msan/./contrib/openssl/crypto/asn1/tasn_dec.c:346:15
#3 0x5571e04043ba in asn1_item_ex_d2i_intern cmake-build-release-msan/./contrib/openssl/crypto/asn1/tasn_dec.c:118:10
#4 0x5571e04043ba in ASN1_item_d2i_ex cmake-build-release-msan/./contrib/openssl/crypto/asn1/tasn_dec.c:144:9
#5 0x5571e04043ba in ASN1_item_d2i cmake-build-release-msan/./contrib/openssl/crypto/asn1/tasn_dec.c:154:12
#6 0x5571e08460ad in ossl_epki2pki_der_decode cmake-build-release-msan/./contrib/openssl/providers/implementations/encode_decode/decode_epki2pki.c:161:13
#7 0x5571e084c5a3 in pem2der_decode cmake-build-release-msan/./contrib/openssl/providers/implementations/encode_decode/decode_pem2der.c:227:18
#8 0x5571e053827e in decoder_process cmake-build-release-msan/./contrib/openssl/crypto/encode_decode/decoder_lib.c:1101:14
#9 0x5571e0537016 in OSSL_DECODER_from_bio cmake-build-release-msan/./contrib/openssl/crypto/encode_decode/decoder_lib.c:82:10
#10 0x5571e067f5c4 in pem_read_bio_key_decoder cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:60:13
#11 0x5571e067f5c4 in pem_read_bio_key cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:241:11
#12 0x5571e06801d3 in PEM_read_bio_PrivateKey_ex cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:304:12
#13 0x5571e0350beb in SSL_CTX_use_PrivateKey_file cmake-build-release-msan/./contrib/openssl/ssl/ssl_rsa.c:415:16
#14 0x5571dd4dfa6a in Poco::Net::Context::init(Poco::Net::Context::Params const&) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/Context.cpp:296:14
#15 0x5571dd4deb28 in Poco::Net::Context::Context(Poco::Net::Context::Usage, Poco::Net::Context::Params const&) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/Context.cpp:54:2
#16 0x5571dd4f5c2d in Poco::Net::SSLManager::initDefaultContext(bool) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/SSLManager.cpp:287:34
#17 0x5571dd4f220b in Poco::Net::SSLManager::defaultServerContext() cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/SSLManager.cpp:125:3
#18 0x5571cf03e24e in DB::CertificateReloader::findOrInsert(ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:134:57
#19 0x5571cf038968 in DB::CertificateReloader::tryLoadImpl(Poco::Util::AbstractConfiguration const&, ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:202:19
#20 0x5571cf0377be in DB::CertificateReloader::tryLoad(Poco::Util::AbstractConfiguration const&, ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:117:5
#21 0x5571cf0377be in DB::CertificateReloader::tryLoad(Poco::Util::AbstractConfiguration const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:104:5
#22 0x5571a6dd25b6 in DB::Server::main(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>> const&) cmake-build-release-msan/./programs/server/Server.cpp:2548:37
#23 0x5571dd55924b in Poco::Util::Application::run() cmake-build-release-msan/./base/poco/Util/src/Application.cpp:315:8
#24 0x5571a6d7be66 in DB::Server::run() cmake-build-release-msan/./programs/server/Server.cpp:660:25
#25 0x5571dd5a373a in Poco::Util::ServerApplication::run(int, char**) cmake-build-release-msan/./base/poco/Util/src/ServerApplication.cpp:131:9
#26 0x5571a6d73b43 in mainEntryClickHouseServer(int, char**) cmake-build-release-msan/./programs/server/Server.cpp:447:20
#27 0x55718152671d in main cmake-build-release-msan/./programs/main.cpp:380:21
#28 0x7feb2b627634 in __libc_start_call_main /usr/src/debug/glibc/glibc/csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#29 0x7feb2b6276e8 in __libc_start_main /usr/src/debug/glibc/glibc/csu/../csu/libc-start.c:360:3
#30 0x55718148ce6d in _start (/home/thevar1able/nvmemount/clickhouse/cmake-build-release-msan/programs/clickhouse+0xa889e6d) (BuildId: 0ab37401c8c27a02d94eb81b9cc50d79736b4266)
Uninitialized value was created by a heap allocation
#0 0x55718151d58d in malloc (/home/thevar1able/nvmemount/clickhouse/cmake-build-release-msan/programs/clickhouse+0xa91a58d) (BuildId: 0ab37401c8c27a02d94eb81b9cc50d79736b4266)
#1 0x5571e0634a19 in CRYPTO_malloc cmake-build-release-msan/./contrib/openssl/crypto/mem.c:211:11
#2 0x5571e06840ef in PKCS12_pbe_crypt_ex cmake-build-release-msan/./contrib/openssl/crypto/pkcs12/p12_decr.c:78:16
#3 0x5571e0845f0a in ossl_epki2pki_der_decode cmake-build-release-msan/./contrib/openssl/providers/implementations/encode_decode/decode_epki2pki.c:143:18
#4 0x5571e084c5a3 in pem2der_decode cmake-build-release-msan/./contrib/openssl/providers/implementations/encode_decode/decode_pem2der.c:227:18
#5 0x5571e053827e in decoder_process cmake-build-release-msan/./contrib/openssl/crypto/encode_decode/decoder_lib.c:1101:14
#6 0x5571e0537016 in OSSL_DECODER_from_bio cmake-build-release-msan/./contrib/openssl/crypto/encode_decode/decoder_lib.c:82:10
#7 0x5571e067f5c4 in pem_read_bio_key_decoder cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:60:13
#8 0x5571e067f5c4 in pem_read_bio_key cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:241:11
#9 0x5571e06801d3 in PEM_read_bio_PrivateKey_ex cmake-build-release-msan/./contrib/openssl/crypto/pem/pem_pkey.c:304:12
#10 0x5571e0350beb in SSL_CTX_use_PrivateKey_file cmake-build-release-msan/./contrib/openssl/ssl/ssl_rsa.c:415:16
#11 0x5571dd4dfa6a in Poco::Net::Context::init(Poco::Net::Context::Params const&) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/Context.cpp:296:14
#12 0x5571dd4deb28 in Poco::Net::Context::Context(Poco::Net::Context::Usage, Poco::Net::Context::Params const&) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/Context.cpp:54:2
#13 0x5571dd4f5c2d in Poco::Net::SSLManager::initDefaultContext(bool) cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/SSLManager.cpp:287:34
#14 0x5571dd4f220b in Poco::Net::SSLManager::defaultServerContext() cmake-build-release-msan/./base/poco/NetSSL_OpenSSL/src/SSLManager.cpp:125:3
#15 0x5571cf03e24e in DB::CertificateReloader::findOrInsert(ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:134:57
#16 0x5571cf038968 in DB::CertificateReloader::tryLoadImpl(Poco::Util::AbstractConfiguration const&, ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:202:19
#17 0x5571cf0377be in DB::CertificateReloader::tryLoad(Poco::Util::AbstractConfiguration const&, ssl_ctx_st*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:117:5
#18 0x5571cf0377be in DB::CertificateReloader::tryLoad(Poco::Util::AbstractConfiguration const&) cmake-build-release-msan/./src/Server/CertificateReloader.cpp:104:5
#19 0x5571a6dd25b6 in DB::Server::main(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>> const&) cmake-build-release-msan/./programs/server/Server.cpp:2548:37
#20 0x5571dd55924b in Poco::Util::Application::run() cmake-build-release-msan/./base/poco/Util/src/Application.cpp:315:8
#21 0x5571a6d7be66 in DB::Server::run() cmake-build-release-msan/./programs/server/Server.cpp:660:25
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
MergeDate: Tue Jan 20 18:19:16 2026
(Merged from openssl#29647)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )