1
0
mirror of https://github.com/MariaDB/server.git synced 2026-10-23 18:49:29 +03:00
Files
Vladislav Vaintroub fb641b0cd1 MDEV-40287 AES_ENCRYPT() and KDF() return NULL with OpenSSL 4.0
MyCTX used an EVP_CIPHER_CTX in a stack buffer instead of allocating it
with EVP_CIPHER_CTX_new(). OpenSSL 4.0 rejects a context that was not
created that way for ciphers that use an IV: EVP_CipherInit_ex() fails
with "invalid iv length", so AES_ENCRYPT() and KDF() in CBC/CTR/GCM
modes return NULL. ECB has no IV and still works, which is why only the
non-ECB modes broke.

Allocate the context with EVP_CIPHER_CTX_new()/EVP_CIPHER_CTX_free(), and
on an init error free and null it, so a later update()/finish() from a
caller that ignored the error is a safe no-op, not a double free. Remove
check_openssl_compatibility() and the EVP_CIPHER_CTX_SIZE and
EVP_CIPHER_CTX_init macros.

my_md5() used the same stack-buffer-sized-by-EVP_MD_CTX_SIZE hack, whose
only guard was check_openssl_compatibility(). MD5_CTX is a concrete struct
in both OpenSSL and WolfSSL, so use it directly with MD5_Init/Update/Final
on a caller-owned context, like my_sha.inl does for SHA*_CTX; this removes
the EVP_MD_CTX hack and EVP_MD_CTX_SIZE. The exception is OpenSSL 1.0.x,
which aborts on the low-level MD5 API in FIPS mode (MDEV-7788): there, and
only there, keep the EVP path with the non-FIPS flag. 1.1.0 removed the
FIPS Object Module and 3.0+ low-level MD5 bypasses the provider, so the
concrete MD5_CTX is correct on every other version. SHA is unaffected, it
already used concrete SHA*_CTX structs.

Verified against OpenSSL 4.0.1: the mysys aes-t test fails on the
CBC/CTR/GCM cases with the stack buffer and passes with
EVP_CIPHER_CTX_new(). The 1.0.x MD5 path verified against a FIPS build of
OpenSSL 1.0.2u: the EVP path computes MD5, the low-level path aborts.

No visible performance degradation: the extra allocation costs
~12 ns/call (WolfSSL) and ~30 ns (OpenSSL) on Windows at a 30-byte
payload, nothing at 16 KB, and nothing on Linux/glibc; sysbench OLTP
over encrypted tables and redo log is unchanged.

Tests main.tlsv13 and main.ssl_crl: OpenSSL 4.0.3 reports TLS alerts as
"tls alert ..." (was "ssl/tls alert ..."), accept both.

Assisted-by: Claude:claude-opus-4-8
2026-10-20 01:59:37 +02:00
..
2022-02-09 19:13:52 +01:00
2019-05-11 19:25:02 +03:00
2022-01-21 16:02:34 +01:00
2024-11-29 13:43:17 +02:00
2025-11-11 10:29:45 +02:00
2019-05-11 22:19:05 +03:00
2019-05-11 19:25:02 +03:00
2023-12-18 11:19:04 +01:00
2023-01-03 17:08:42 +02:00
2020-06-19 19:43:07 +02:00
2022-11-08 17:01:28 +02:00
2023-12-18 11:19:04 +01:00
2023-04-24 12:43:47 +02:00
2023-02-10 13:03:01 +02:00
2024-03-28 09:16:57 +02:00
2019-05-11 22:19:05 +03:00
2023-11-08 12:59:00 +01:00
2019-05-11 22:19:05 +03:00
2026-07-24 17:06:39 +02:00
2022-12-20 08:55:48 +11:00
2023-01-04 14:52:25 +02:00
2019-05-11 21:29:06 +03:00
2019-05-11 21:29:06 +03:00
2019-05-11 22:19:05 +03:00
2019-05-11 21:29:06 +03:00
2022-07-31 14:54:37 +02:00
2019-05-14 17:18:46 +03:00
2019-05-11 21:29:06 +03:00
2019-05-14 17:18:46 +03:00
2025-09-04 18:08:39 +03:00
2019-05-19 20:55:37 +02:00
2019-05-11 22:19:05 +03:00
2020-10-29 13:38:38 +02:00
2023-12-18 11:19:04 +01:00
…
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2020-03-10 19:24:22 +01:00
2019-05-11 21:29:06 +03:00
2019-05-11 21:29:06 +03:00
2019-05-11 21:29:06 +03:00
2023-12-17 11:20:43 +01:00
2019-05-11 21:29:06 +03:00
2022-12-20 08:55:48 +11:00
2019-05-11 21:29:06 +03:00
2019-05-14 17:18:46 +03:00