Enforce max_body_size on the deflate path (CVE-2026-65060)

[oalders]

Fixes #206. CVE-2026-65060.

decoded_content() did not apply max_body_size (or the global $HTTP::Message::MAXIMUM_BODY_SIZE) to Content-Encoding: deflate, nor to its raw-deflate fallback, while gzip, x-gzip and bzip2 all honoured it. A hostile or compromised server could bypass the limit entirely just by labelling a decompression bomb deflate.

Measured, with a 1 MB limit set:

	before	after
10 MB bomb	decodes all 10,000,000 bytes	refused
4 GB bomb	Out of memory in perl:util:safesysrealloc	dies in 0.10s at 18 MB RSS

Approach

The obvious fix is to reimplement inflate on top of Compress::Raw::Zlib, matching what the gzip branch does. This does not do that. It keeps the existing IO::Uncompress decoder and bounds it with a new _uncompress() helper.

The reason is behavioural compatibility. IO::Uncompress::Inflate and Compress::Raw::Zlib do not agree on multi-member streams, trailing garbage, or transparent pass-through of undecodable content. Swapping decoders would have changed all three as a side effect of a security fix. Bounding the existing one makes the cap a purely additional constraint.

With a limit in force, the decoder is asked for exactly one octet more than the limit allows. That is enough to tell content that fits from content that does not, and it is never more memory than the caller has already agreed to hand over -- the same bound the gzip branch gets from Bufsize => $content_limit.

With no limit in force, the stream is read to its end a block at a time, which is what the one-shot IO::Uncompress functions called by the previous code do internally. That split is not cosmetic: asking for a fixed number of octets takes a different path through IO::Uncompress::Base, and that path mis-reports the end of some raw deflate streams on perls older than 5.20. The unlimited path was verified byte-identical to the one-shot interface across eleven edge cases (empty input, truncated streams, multi-member, trailing garbage, non-deflate content, high-ratio bombs, and so on) on perl 5.10, 5.12, 5.18 and 5.42, using the perldocker/perl-tester images CI runs.

Also in this change

A negative max_body_size is now rejected. Each decoder reacted differently to one; the deflate path quietly returned no content at all, which is indistinguishable from a successful decode of an empty body. It now dies.

max_body_size() and $HTTP::Message::MAXIMUM_BODY_SIZE are documented. They had no Pod at all. The new Pod covers the decompression-bomb rationale, the block-sized overshoot (so callers leave headroom), which encodings enforce the limit, why base64 and quoted-printable are exempt (neither can expand its input), and that br cannot distinguish an over-limit body from a corrupt one.

Tests

t/message-decode-deflatebomb.t is new: 18 assertions covering both the zlib-deflate and raw-deflate forms.

• the cap is enforced on both, and the error names the limit
• the per-call max_body_size parameter caps a body too
• without raise_error, an over-large body yields undef rather than a bomb
• bodies under the cap, and exactly at the cap, still decode correctly
• negative limits (-1, -1000) are rejected
• a stream that stops mid-block is refused both with and without a limit, and the raw-deflate failure is reported in Client-Warning
• undecodable content is still passed through unchanged

That last one pins pre-existing behaviour rather than asserting what I first expected: IO::Uncompress::RawInflate defaults to Transparent => 1, so content that is not deflate at all comes back untouched. It is not amplified, so the cap has nothing to protect against there, and the test now documents that deliberately.

Every cap assertion was confirmed to fail against the unpatched code before the fix went in. The suite passes on perl 5.10, 5.12, 5.18, 5.20 and 5.42.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.86%. Comparing base (c200e42) to head (b1fa67e).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #231      +/-   ##
==========================================
+ Coverage   94.50%   94.86%   +0.36%     
==========================================
  Files          10       10              
  Lines        1256     1267      +11     
  Branches      351      358       +7     
==========================================
+ Hits         1187     1202      +15     
+ Misses         14       12       -2     
+ Partials       55       53       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[robrwo]

I don't like the idea if reading an extra byte just to check if there is more data.

Would the following work instead?

my $read = $z->read( $output, $limit );
	return undef if !defined $read || $read < 0;
Carp::croak("Decoded content would be larger than $limit octets") unless $z->eof;

Question: would it make more sense to simple warn/carp?