GHSA-qcwq-55hx-v3vh — snappy-java's unchecked chunk length leads to DoS

Affected: Maven: org.xerial.snappy:snappy-java

## Summary Due to use of an unchecked chunk length, an unrecoverable fatal error can occur. ## Impact Denial of Service ## Description The code in the function [hasNextChunk](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/SnappyInputStream.java#L388) in the file [SnappyInputStream.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/SnappyInputStream.java) checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.

```java int readBytes = readNext(header, 0, 4); if (readBytes < 4) { return false; }

int chunkSize = SnappyOutputStream.readInt(header, 0); if (chunkSize == SnappyCodec.MAGIC_HEADER_HEAD) { ......... }

// extend the compressed data buffer size if (compressed == null || chunkSize > compressed.length) { compressed = new byte[chunkSize]; }

```

In the case that the “compressed” variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the “chunkSize” variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a “java.lang.NegativeArr…

Most recent entries from all

GHSA-qcwq-55hx-v3vh — snappy-java's unchecked chunk length leads to DoS