fix(tonic): respect max_message_size when decompressing a message#2484
Merged
LucioFranco merged 2 commits intohyperium:masterfrom Jan 28, 2026
Merged
Conversation
This patch fixes a bug where the configured max_message_size is not respected when a payload is compressed, leading the possibility of over allocating and exhausting memory over the configured maximum message size when decompressing the message.
Contributor
Author
|
Let me know if you'd like me to open up an identical PR against the |
LucioFranco
reviewed
Jan 26, 2026
LucioFranco
approved these changes
Jan 28, 2026
LucioFranco
added a commit
that referenced
this pull request
Jan 28, 2026
# Changelog for v0.14.3 ## Features - Expose `tcp_keepalive_interval` and `tcp_keepalive_retries` options on Server (#2472) - Allow configuration of `max_local_error_reset_streams` on Server (#2437) - Put source error into the `Display` impl of `Status` (#2417) - `Server::default()` now sets `TCP_NODELAY` to true (#2413) ## Bug Fixes - Respect `max_message_size` when decompressing a message (#2484) - Depend on http at least 1.1.0 (#2426) ## Documentation - Fix documentation links for timeout configuration (#2483) - Fix documentation typos and grammar issues in status.rs and codec/mod.rs (#2468) - Fix labels in `Display for Status` (#2414) - Fix features docs in tonic-build and tonic-prost-build (#2434) - Remove redundant word in tonic-build and tonic-prost-build README (#2425)
grembo
pushed a commit
to grembo/tonic
that referenced
this pull request
Feb 3, 2026
…perium#2484) This patch fixes a bug where the configured max_message_size is not respected when a payload is compressed, leading the possibility of over allocating and exhausting memory over the configured maximum message size when decompressing the message. ## Motivation When compression is enabled, and a compressed message is sent or received, the configured max_message_size (for both clients and servers) is only checked against the compressed message size and that limit is not respected for the resulting uncompressed message, which can lead to resource exhaustion. ## Solution Respect the configured, or default, max_message_size limit while decompressing a message, returning an error if the resultant decompressed message would exceed the limit.
LucioFranco
pushed a commit
that referenced
this pull request
Feb 13, 2026
) This patch fixes a bug where the configured max_message_size is not respected when a payload is compressed, leading the possibility of over allocating and exhausting memory over the configured maximum message size when decompressing the message. ## Motivation When compression is enabled, and a compressed message is sent or received, the configured max_message_size (for both clients and servers) is only checked against the compressed message size and that limit is not respected for the resulting uncompressed message, which can lead to resource exhaustion. ## Solution Respect the configured, or default, max_message_size limit while decompressing a message, returning an error if the resultant decompressed message would exceed the limit.
LucioFranco
added a commit
that referenced
this pull request
Feb 13, 2026
- Expose `tcp_keepalive_interval` and `tcp_keepalive_retries` options on Server (#2472) - Allow configuration of `max_local_error_reset_streams` on Server (#2437) - Put source error into the `Display` impl of `Status` (#2417) - `Server::default()` now sets `TCP_NODELAY` to true (#2413) - Respect `max_message_size` when decompressing a message (#2484) - Depend on http at least 1.1.0 (#2426) - Fix documentation links for timeout configuration (#2483) - Fix documentation typos and grammar issues in status.rs and codec/mod.rs (#2468) - Fix labels in `Display for Status` (#2414) - Fix features docs in tonic-build and tonic-prost-build (#2434) - Remove redundant word in tonic-build and tonic-prost-build README (#2425)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch fixes a bug where the configured max_message_size is not respected when a payload is compressed, leading the possibility of over allocating and exhausting memory over the configured maximum message size when decompressing the message.
Motivation
When compression is enabled, and a compressed message is sent or received, the configured max_message_size (for both clients and servers) is only checked against the compressed message size and that limit is not respected for the resulting uncompressed message, which can lead to resource exhaustion.
Solution
Respect the configured, or default, max_message_size limit while decompressing a message, returning an error if the resultant decompressed message would exceed the limit.