From: Willy Tarreau <w@1wt.eu>
Date: Wed, 3 Jun 2026 11:23:32 +0000 (+0200)
Subject: BUG/MINOR: jwe: don't write randoms past MAX_DECRYPTED_CEK_LEN in RSA_PKCS1_PADDING
X-Git-Tag: v3.4.0~5
X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=bf4878226e68a45e1daa7ebe397bfb68f44b8634;p=thirdparty%2Fhaproxy.git

BUG/MINOR: jwe: don't write randoms past MAX_DECRYPTED_CEK_LEN in RSA_PKCS1_PADDING

The recent fix in commit 1a5a33396d ("BUG/MEDIUM: jwe: substitute random
CEK on RSA1_5 decryption failure per RFC 7516 #11.5") writes 8 bytes at
once but stops at the last one, so it can overflow the sample by 7 bytes.
This is totally harmless since the max size is 64 bytes, but better stop
at the boundary. A final loop completes one byte at a time by construction
so that we can adapt to any value of MAX_DECRYPTED_CEK_LEN, but the compiler
will not emit it since we stop at 64.

No backport is needed, it's only for 3.4.
---

diff --git a/src/jwe.c b/src/jwe.c
index ec00a19a8..3729d7525 100644
--- a/src/jwe.c
+++ b/src/jwe.c
@@ -840,11 +840,16 @@ static int do_decrypt_cek_rsa(struct buffer *cek, struct buffer *decrypted_cek,
 			int i;
 			unsigned char *p = (unsigned char *)b_orig(decrypted_cek);
 
-			for (i = 0; i < MAX_DECRYPTED_CEK_LEN; i++) {
+			/* fill 8 bytes at a time */
+			for (i = 0; i <= MAX_DECRYPTED_CEK_LEN - 8; i++) {
 				uint64_t r = ha_random64();
 				memcpy(p, &r, 8);
-				p+=8;
+				p += 8;
 			}
+			/* complete if not multiple of 8 (normally not the case) */
+			for (; i < MAX_DECRYPTED_CEK_LEN; i++)
+				*(p++) = ha_random64();
+
 			outl = MAX_DECRYPTED_CEK_LEN;
 		} else
 			goto end;