Found with the configuration running the unit test through valgrind.
% ./configure CFLAGS=-DNO_WOLFSSL_CIPHER_SUITE_TEST \
--enable-all --disable-fastmath --enable-debug --disable-shared
1. ssl.c: In wolfSSL_DSA_generate_key(), we initialize (and allocate)
all the parameters in the key (p, q, g, x, y), and then we generate a
key, initializes (and allocates) x and y, again. mp_clear them
first.
2. evp.c: When printing public keys, the temporary mp_int wasn't getting
correctly freed.
3. evp.c: When printing public keys, modified the utility functions to
return once with a do-while-0 loop.
pskNegotiated field added to indicate Session Ticket or PSK negotiated.
peerAuthGood field added to indicate that any require peer
authentication (certificate, if required, or PSK) have been performed.
When compiling with the CFLAG -m32, sp_c32.c is used and not sp_c64.c.
The build system cannot detect that this is a 32-bit platform and to use
sp_c32.c.
The SP code detects which implementaiton to use and sets defines that
enable the code in sp_c32.c or sp_c64.c.
ENABLED_64BIT, 64-bit platform, was on by default, which is not always
true.
By making ENABLED_64BIT not default then the decision of which SP C
files to include in the build had to change to not being the other.
That is, sp_c64.c is not included when the configuration line explicitly
enables 32bit and sp_c32.c is not include when the configuration line
explicitly enables 64bit.
* whitespace in src/ssl.c, tests/api.c, wolfssl/openssl/fips_rand.h.
* clang-analyzer-core.StackAddressEscape from llvm-15 clang-tidy, in tests/suites.c:execute_test_case().
* bugprone-suspicious-memory-comparison from llvm-15 clang-tidy, in src/internal.c:DoSessionTicket() and src/ssl.c:wolfSSL_sk_push().
At the start of this function, it attempts to find an ALPN extension in the
ssl object's extensions with `TLSX_Find`. If an ALPN select callback has been
set (i.e. via `wolfSSL_CTX_set_alpn_select_cb`), that gets called next. If that
callback finds a match, it removes all existing ALPN extensions found in the
ssl object. It then uses the new protocol name like this:
```
if (TLSX_UseALPN(&ssl->extensions, (char*)out, outLen, 0, ssl->heap)
== WOLFSSL_SUCCESS) {
if (extension == NULL) {
extension = TLSX_Find(ssl->extensions,
TLSX_APPLICATION_LAYER_PROTOCOL);
}
}
```
The bug is exposed if `extension` is not NULL, i.e. it was found on that initial
`TLSX_Find` call. `extension` is not NULL but it now points to garbage because
all the old ALPN extensions were just removed. It won't have it's value assigned
to the new extension that just got pushed via `TLSX_UseALPN` because of this
NULL check. This results in a segfault later in the function.
The solution is to remove the NULL check and always update `extension` after the
`TLSX_UseALPN` call.
This bug was discovered by a customer when using nginx + wolfSSL. I was able to
reproduce locally with curl acting as the client
