]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MINOR: slz: fix the adler32 accumulators signedness on 32-bit
authorWilly Tarreau <w@1wt.eu>
Sun, 26 Jul 2026 21:54:06 +0000 (23:54 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 28 Jul 2026 14:14:53 +0000 (16:14 +0200)
slz_adler32_block() unfortunately uses a signed long as the crc accumulator
instead of an unsigned one, meaning that for CRC values where the 32th bit
is set on 32-bit machines, the right shift will drag sign bits and corrupt
it. This only affects zlib streams on 32-bit systems (rfc1950) and has
been there for a very long time, showing that the zlib format is really
not much used in target environments.

The fix is trivial, just change the accumulators to unsigned long.

This must be backported to 1.2. It was in slz.c prior to 1.3.0.

This is libslz upstream commit 912a707525fd2d6a63c9884ef02f69e7379c304c.

Note: the impact in haproxy is the "zlib" compression algorithm often
      causing CRC errors on clients when haproxy runs on a 32-bit
      system. Since "zlib" has long been avoided due to incompatibilities
      with certain clients in the past, the impact should be almost
      inexistent (this issue was never reported).

src/slz.c

index f50946ff100e9099c77fc7cc7f8974860978aa6e..627f195756368eae417ed57f8b2f66e3e515cacb 100644 (file)
--- a/src/slz.c
+++ b/src/slz.c
@@ -1427,8 +1427,8 @@ uint32_t slz_adler32_by1(uint32_t crc, const unsigned char *buf, int len)
  */
 uint32_t slz_adler32_block(uint32_t crc, const unsigned char *buf, long len)
 {
-       long s1 = crc & 0xffff;
-       long s2 = (crc >> 16);
+       unsigned long s1 = crc & 0xffff;
+       unsigned long s2 = (crc >> 16);
        long blk;
        long n;