Reject invalid literal/length and distance codes in Deflate64 decoder#785
Open
kali834x wants to merge 1 commit into
Open
Reject invalid literal/length and distance codes in Deflate64 decoder#785kali834x wants to merge 1 commit into
kali834x wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR hardens the Deflate64 HuffmanDecoder against malformed/invalid Huffman streams by validating decoded literal/length and distance symbols before table lookups, preventing out-of-bounds access and ensuring failures surface as CompressorExceptions rather than runtime errors.
Changes:
- Validate decoded literal/length symbols (including reserved 286/287 and
-1) before indexingRUN_LENGTH_TABLE. - Validate decoded distance symbols (reject
-1and out-of-range) before indexingDISTANCE_TABLE. - Add a regression test that emits fixed-Huffman literal/length symbol 286 and asserts rejection.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/main/java/org/apache/commons/compress/compressors/deflate64/HuffmanDecoder.java | Adds explicit bounds checks for literal/length and distance symbols and throws CompressorException on invalid codes. |
| src/test/java/org/apache/commons/compress/compressors/deflate64/HuffmanDecoderTest.java | Adds a regression test ensuring reserved fixed-Huffman literal/length code 286 is rejected with a clear error. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
188
to
+191
| final int distSym = nextSymbol(reader, distanceTree); | ||
| if (distSym < 0 || distSym >= DISTANCE_TABLE.length) { | ||
| throw new CompressorException("Invalid Deflate64 distance code %,d", distSym); | ||
| } |
Member
|
Hello @kali834x |
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
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.
Deflate64's HuffmanDecoder decodes a literal/length symbol from the bit stream and uses it to index RUN_LENGTH_TABLE, and a distance symbol to index DISTANCE_TABLE, without checking either against the table bounds. The fixed literal/length tree assigns codes to symbols 286 and 287, which RFC 1951 reserves and which have no RUN_LENGTH_TABLE entry, so a stream that emits one of those codes runs symbol - 257 past the end of the 29-element table. An incomplete dynamic tree is also decodable to -1, which on the length side is silently written out as a 0xFF literal and on the distance side indexes DISTANCE_TABLE[-1]. I hit the length case first with a hand-built fixed-Huffman block holding the code for 286, which threw ArrayIndexOutOfBoundsException out of decode rather than a CompressorException. The fix checks each decoded symbol against its table before the lookup and rejects the out-of-range ones, which matches how the .Z and bzip2 decoders here already reject invalid codes. Added a HuffmanDecoderTest case for the 286 stream.