GHSA-6cx8-rjf8-pr8g: Medium severity maven/org.lz4:lz4-java vulnerability

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.