grpc: limit decompression size in legacy gzip Decompressor to prevent OOM

[evilgensec]

Summary

The legacy gzipDecompressor.Do() (used when a server is configured with the deprecated grpc.RPCDecompressor(grpc.NewGZIPDecompressor()) option) calls io.ReadAll(z) with no size bound. The size limit check happens after the full payload is materialized in memory:

// decompress():
uncompressed, err := dc.Do(r)          // io.ReadAll — full payload in memory
...
if len(uncompressed) > maxReceiveMessageSize {   // too late

A client can send a highly compressed gRPC frame (e.g., 1 KiB of gzip expanding to 1+ GiB) and force the server to buffer the entire expanded payload before the MaxRecvMsgSize limit fires.

The modern encoding.Compressor path already uses io.LimitReader(dcReader, limit+1) to prevent this (lines 993–1010). The deprecated path did not have the equivalent guard.

Fix

Wrap the reader passed to dc.Do with io.LimitReader(maxReceiveMessageSize+1), matching the behavior of the safe code path.

Scope

Only affects servers explicitly configured with grpc.RPCDecompressor(grpc.NewGZIPDecompressor()). The default server uses the encoding.Compressor path and is unaffected.

RELEASE NOTES:

• grpc: limit decompression size in legacy gzip Decompressor to MaxRecvMsgSize

[Copilot]

Pull request overview

This PR hardens the deprecated grpc.Decompressor (legacy gzipDecompressor.Do() / grpc.RPCDecompressor(grpc.NewGZIPDecompressor())) receive path against decompression bombs by ensuring decompression cannot expand unbounded in memory before MaxRecvMsgSize is enforced.

Changes:

• Wrap the legacy decompressor input reader with io.LimitReader(maxReceiveMessageSize+1) to bound decompression output prior to the post-decompression size check.
• Add explanatory comments documenting the OOM risk and rationale for the limit.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.10%. Comparing base (037c6ef) to head (b38765f).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9114      +/-   ##
==========================================
- Coverage   83.20%   83.10%   -0.11%     
==========================================
  Files         417      417              
  Lines       33648    33658      +10     
==========================================
- Hits        27998    27971      -27     
- Misses       4235     4256      +21     
- Partials     1415     1431      +16     

Files with missing lines	Coverage Δ
rpc_util.go	83.50% <100.00%> (+0.43%)	⬆️

... and 25 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[easwars]

The legacy gzip compressor has been deprecated for over 8 years. So, while this fix is valid, it probably doesn't represent any real security vulnerability, because there is hardly going to be anyone using this.

[easwars]

@arjan-bal for second set of eyes

[arjan-bal]

I took a look, and it seems like the current code is restricting the size of the compressed message rather than the decompressed payload. If the goal was to check the compressed size, a more straightforward approach might be to check the length of the message buffer (d.Len()) directly.

However, it looks like the check for the compressed message length already exists here, which might make this current fix redundant.

If the goal is to protect against zip bombs, we'll need to limit the decompressed size instead. I think a good way to handle this would be to wrap the gzip reader in an io.LimitReader here.

From there, we could check if the limit was reached, similar to how it's handled in the new gzip compressor here.

Note that it's not possible to pass extra params to the Do method, so we may need to type assert the reader to be a gzip decompressor to pass the max message size.

[evilgensec]

Thanks for the careful look @arjan-bal — you're right, and I've reworked the fix in 50ab251.

You correctly pointed out that the previous version wrapped io.LimitReader around the compressed input, which is redundant with the MaxRecvMsgSize check in parser.recvMsg. The decompressed payload was still unbounded, so the OOM window stayed open.

The updated patch moves the io.LimitReader so it wraps the *gzip.Reader output instead of the input — matching the pattern at lines 996–1013 in the modern encoding.Compressor path. Since Decompressor.Do(r io.Reader) can't take a size parameter, I added an internal doWithMaxSize helper on *gzipDecompressor and type-assert at the decompress() call site to invoke it. Third-party Decompressor implementations fall through to the original Do and are unaffected.

Two tests cover this: TestDecompress_LegacyGzipBomb (1 MiB-of-zeros payload, 1 KiB receive limit → ResourceExhausted instead of full expansion) and TestDecompress_LegacyGzipUnderLimit (legitimate traffic still decompresses correctly).

PTAL when you have a chance.

[arjan-bal]

Looks good, just a couple of minor comments.

[arjan-bal]

LGTM, thanks for the fix! Assigning back to @easwars for a second review since the PR has changed since his previous approval.

[arjan-bal]

The build seems to have broken after renaming the compressWithDeterministicError. Can you please fix it?

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: evilgensec / name: evilgensec (4741525, 50ab251, 5617537, a644fa6, b38765f, cc95cb8, ee97a0a)

[evilgensec]

Dear Team, anything else needed to merge into main?