-
Notifications
You must be signed in to change notification settings - Fork 232
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request from GHSA-qcwq-55hx-v3vh
* asserted chunksize should be in the bounds of 0-java.outofmmeoryexception * asserted chunksize should be in the bounds of 0-java.outofmmeoryexception * https://github.com/xerial/snappy-java-ghsa-qcwq-55hx-v3vh/pull/2 * advisory-fix-3 * added and changed method name for happy and sad cases in SnappyTest.java * removed expected error for happy case in unit testing * added another unit test case in SnappyTest.java and fixed comments in SnappyInputStream.java * switched SnappyError to INVALID_CHUNK_SIZE * Updated unit tests * Resolved conflicts with another PR merge
- Loading branch information
Showing
2 changed files
with
62 additions
and
2 deletions.
There are no files selected for viewing
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
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
3bf6785
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this addresses the issue of DoS.
If the
chunkSize
is too large anOutOfMemoryError
still occurs, it is just wrapped. This does mean that technically the error is now caught by catch block in the program and thus the test case in the advisory passes (most of the time - it may not, since allocating a newSnappyError
after catchingOutOfMemoryError
could fail), but catchingError
s is very rarely a good idea, and libraries downgrading them toException
s and hiding them from applications is definitely not a good idea. IMO this change should be reverted - either thechunkSize
should be validated to be within some bounds (perhaps specified by the application) and anException
thrown without anOutOfMemoryError
occurring, or if a (unbounded)chunkSize
is supported then theOutOfMemoryError
should simply be allowed to occur and applications may catch that if they wish.If the chunkSize is negative the program still crashes, just with a different error - the availability is in no senses improved. However this is a good change of validating the inputs and should be kept regardless.
All that said I think the advisory is probably the one wrong here rather than the code, since throwing an exception for a negative
chunkSize
is the right thing to do if recovering is not possible, as is a library not limiting thechunkSize
. So this definitely shouldn't be a high.