[zstd][#60] Add decompression size sanity Check #115
Merged
Conversation
This file contains 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
Fix #60 Before we were blindly trusting the data returned by ZSTD_getDecompressedSize. This mean with a specifically crafter payload, we would try to allocate a lot of memory resulting in potential DOS. Now set a sane limit and fall back to streaming
Since zstd 1.3.0+, the zstd header has size hint so you should be able to decompress the first time directly with that hint OR directly fallback to streaming. No need to try 3 times
kevinconaway
approved these changes
Apr 14, 2022
|
No real changes on benchmark |
This was referenced Jun 2, 2022
Viq111
added a commit
that referenced
this pull request
Aug 24, 2023
Contrary to Decompress, bulk.Decompress does not retry with stream decompression on failing to Decompress. #115 introduced preventing to allocate too big buffers when the input zstd header was malicious. This had the side-effect that for highly compressed payloads (> 10x), the dst buffer was still resized and would fail. This fixes the issue and adds a test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fix #60 (see for full description).
Previously, we were trusting the input from the zstd header to allocate the memory on
DecompressAPI. This meant a carefully crafted payload could make the zstd wrapper allocates an arbitrary size:After this fix, we correctly don't allocate too much.
The main part of the change is at: 30c4b29#diff-fc46d6feefba07384476b9d2f5a4ae18d6f7322dcd684c388ebe1b2b8d19d394R55-R74
We now basically allocate up to:
min(ZSTD_getFrameContentSize(), max(1MB, 10*input_size))