yawkat LZ4 Java vulnerabilities

In yawkat LZ4 Java prior to 1.11.2, LZ4DecompressorWithLength trusts the four-byte decompressed-length header before validating input, allowing a five-byte input to request up to ~2 GiB and exhaust the JVM heap. Overloads writing to a caller-provided buffer are not affected.

In yawkat LZ4 Java prior to 1.11.2, LZ4BlockInputStream.refill() validates the compressedLen field as nonnegative but allocates a buffer of that attacker-controlled size before reading payload data. A header-only stream can request a near-2 GiB allocation and exhaust the JVM heap.

The yawkat LZ4 Java library versions 1.7.0 through 1.11.4 contain a vulnerability in the insecure creation of a temporary file. An attacker with access to a shared temporary directory can replace the native library file before it is loaded, potentially leading to code execution in the victim's context.

In yawkat LZ4 Java prior to 1.11.4, LZ4FrameInputStream.readHeader() allocates two 4 MiB block buffers for maximum-block-size frame headers, and the default concatenated-frame mode allows streams with many minimal empty frames to trigger ~8 MiB allocation per 11 input bytes without producing output.

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption.

In yawkat LZ4 Java before version 1.11.1, JNI-backed XXHash functions fail to validate the byte array and off/len arguments, allowing null arrays or oversized ranges to reach native code. This can cause reads outside the Java array and fatal JVM termination. Fixed in version 1.11.1.