crypto,quic: missing NULL checks for OpenSSL allocation functions

[UnLucky252]

Version

v22.13.1

Platform

A container based on Ubuntu 22.04 OS

Subsystem

crypto, quic

What steps will reproduce the bug?

This is a set of latent defects found by static analysis (Svace), not
a runtime-reproducible bug. The issues are:

1. src/crypto/crypto_aes.cc, function AES_Cipher (line 46):
   EVP_CIPHER_CTX_new() result used without NULL check.
   Cross-file statistics: checked in 37 of 40 call sites.

2. src/crypto/crypto_aes.cc, function AES_CTR_Cipher2 (line 225):
   EVP_CIPHER_CTX_new() result used without NULL check.
   Same detector, same function.

3. src/crypto/crypto_ec.cc, function ECKeyExportTraits::DoExport
   (line 1264): EC_KEY_new() result used without NULL check.
   Cross-file statistics: checked in 5 of 6 call sites.

4. src/quic/tlscontext.cc, function TLSSession::Initialize (line 2051):
   SSL_new() result used without NULL check.
   Cross-file statistics: checked in 9 of 10 call sites.

5. src/crypto/crypto_cipher.cc, function CipherBase::CommonInit
   (line 2570): EVP_CIPHER_CTX_new() result wrapped in unique_ptr
   and used without verifying it's non-null.

How often does it reproduce? Is there a required condition?

Would manifest under memory pressure when OpenSSL fails to allocate
internal structures. Not trivially reproducible in normal operation.

What is the expected behavior? Why is that the expected behavior?

Allocation failures should result in a controlled error (thrown
JavaScript exception or appropriate error status), not a NULL pointer
dereference / segmentation fault.

What do you see instead?

Potential SIGSEGV on allocation failure.

Additional information

These findings come from the ISPRAS open-source static analysis
working group. All issues are of the same class (OpenSSL allocation
function return value used without NULL check) and can be fixed
together.