]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MINOR: jwe: don't write randoms past MAX_DECRYPTED_CEK_LEN in RSA_PKCS1_PADDING
authorWilly Tarreau <w@1wt.eu>
Wed, 3 Jun 2026 11:23:32 +0000 (13:23 +0200)
committerWilly Tarreau <w@1wt.eu>
Wed, 3 Jun 2026 12:45:54 +0000 (14:45 +0200)
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.

src/jwe.c

index ec00a19a8760c45144c44fe5bed6dd9509820538..3729d75259ddce85cf556c5a5ed8986eae70d479 100644 (file)
--- 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;