Vulnerability details

### Summary `LZ4DecompressorWithLength.decompress(byte[], int)` allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says `0x40000000` makes the JVM commit a gigabyte and can cause heap exhaustion. ### Details `net.jpountz.lz4.LZ4DecompressorWithLength` reads the header and passes it straight on: ```java final int destLen = getDecompressedLength(src, srcOff); return fastDecompressor.decompress(src, srcOff + 4, destLen); ``` and `net.jpountz.lz4.LZ4FastDecompressor` allocates it: ```java public final byte[] decompress(byte[] src, int srcOff, int destLen) { final byte[] decompressed = new byte[destLen]; decompress(src, srcOff, decompressed, 0, destLen); return decompressed; } ``` `getDecompressedLength` performs no validation: no comparison against `src.length`, no ceiling, no rejection of negatives. `LZ4SafeDecompressor.decompress(byte[], int, int, int)` has the same shape with `maxDestLen`. The sibling overload that callers pass their own buffer to, `decompress(src, srcOff, dest, destOff, destLen)`, is fine, because there `destLen` is chosen by the caller rather than by the input. The bug is specific to the convenience overloads that take the size from the header, and that difference is the whole finding. ### Impact Any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte message. On a service that decompresses request bodies, a few concurrent 5-byte requests exhaust the heap. No privileges are needed, only the ability to get bytes into the decompressor. Confidentiality and integrity are untouched.