When decompressing and a gzip/zlib sub-stream returns TOR_COMPRESS_DONE with input bytes remaining, `tor_compress_impl()` frees the backend state and creates a fresh one (lines 156–163) so that multiple concatenated streams can be decoded. Creating a fresh `tor_zlib_compress_state_t` resets that state's `input_so_far` / `output_so_far` counters to zero. Those counters are what the **inner** per-stream compression-bomb check in `tor_zlib_compress_process()` (`compress_zlib.c:241-246`) uses. Therefore an attacker can concatenate N gzip members, each of which decompresses to just under `CHECK_FOR_COMPRESSION_BOMB_AFTER` (5 MiB), and the inner bomb check will **never** fire. Every fresh stream's `output_so_far` stays below the 5 MiB threshold. Because we have `MAX_DIR_DL_SIZE = 16 MB`, it means a malicious relay can make a 16MB request do ~400MB of allocation on the client for that single request. On a tor client phone, this would be pretty bad.