]> git.kaiwu.me - haproxy.git/commit
IMPORT: uslz: do not replay the header-detection bytes on the raw deflate path
authorWilly Tarreau <w@1wt.eu>
Sun, 23 Aug 2026 10:42:34 +0000 (12:42 +0200)
committerWilliam Lallemand <wlallemand@haproxy.com>
Tue, 1 Sep 2026 11:47:07 +0000 (13:47 +0200)
commite0fe1be1c8edb381f99aa221d839cf22730f1422
treea59dce6153e0b64b92e13785345539a08eb68854
parentefe1099c37c934a2f053e627ac295de40e77ef01
IMPORT: uslz: do not replay the header-detection bytes on the raw deflate path

When a stream turns out to be raw deflate and the first two bytes had to
be accumulated into hdr_detect.buf across calls, those bytes are replayed
to uslz_decode_block() from a local array, after which the code did:

state->in_ptr = (const unsigned char *)compressed_data;
state->in_top = state->in_ptr + compressed_size;

That rewinds to the start of the caller's buffer, but the loop that
filled hdr_detect.buf consumed from that same buffer, so the bytes just
replayed were handed to the decoder a second time. Saving the real
in_ptr across the replay fixes it; in_top never moved, and is saved with
it only for symmetry.

The problem happens whenever a raw deflate stream is fed in chunks of 1
or 2 bytes, since 3 or more takes the fast path at "in_top - in_ptr > 2"
and never enters this branch. Feeding 5000 bytes of source through
uslz_decode() one byte at a time failed with USLZ_DECODE_E_GEN_HUFF and
no output at all: the duplicated bytes shift the bit stream, so the first
dynamic block's code lengths no longer form a valid tree. gzip and zlib
streams are unaffected, they leave this branch by a different location.

The issue was spotted by Qwen-3.8-27B. This fix must be backported to
1.3.

This is libslz upstream commit f052863a91aeb44021ed1bd52f680df45667496a
src/uslz.c