]> git.kaiwu.me - haproxy.git/commit
BUG/MINOR: ssl: don't pass the address of a size_t as an int* to OpenSSL
authorRemi Tricot-Le Breton <rlebreton@haproxy.com>
Thu, 6 Aug 2026 07:35:00 +0000 (09:35 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 10 Sep 2026 13:13:26 +0000 (15:13 +0200)
commit3fb37e82618c08e36fb9e40de1d186e7de8b8b6b
tree47f4f24656989ff1b67b4d5dc23dce4f68773ce5
parent79082c7c2b7a721587fdc08347a4cb17dfe37fd6
BUG/MINOR: ssl: don't pass the address of a size_t as an int* to OpenSSL

aes_process() passes &out->data, which is a size_t, to the EVP update and
final routines through an (int*) cast. OpenSSL writes an int there, so on
a 64-bit big-endian platform (s390x, ppc64) the resulting length lands in
the high half of the size_t, and the buffer's data count becomes the real
length shifted left by 32 bits. The subsequent write at out->area +
out->data then targets a wild address.

Concretely, on such builds the "aes_gcm_dec" / "aes_cbc_dec" converters
and the JWE decryption paths corrupt memory as soon as they process any
input, so any client able to submit a token to them can crash the worker.
Little-endian builds, which are the vast majority, happen to work by
chance since the count starts at zero and only the low half is written.

Let's use a proper local int for the OpenSSL output length and assign it
back to the buffer's data count.

The shared helper comes from commit f0e64de75 ("MINOR: ssl: Factorize AES
GCM data processing") in 3.4 but the same cast existed in the AES
converters before that. It must be backported to all stable versions.

Reported-by: Claude (ANT-2026-74N8W6SJ)
src/ssl_sample.c