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).
*/
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;