GHSA-4v53-57pg-c464 yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header

• Maven at.yawk.lz4:lz4-java: < 1.11.2 → fixed in 1.11.2 • Maven org.lz4:lz4-java: <= 1.8.1 (no fix yet)

Summary `LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap. Details In `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation: ```java case COMPRESSION_METHOD_LZ4: if (compressedBuffer.length = o) { compressMethod = COMPRESSION_METHOD_RAW; compressedLength = o; } else { compressMethod = COMPRESSION_METHOD_LZ4; } ``` Existing readers generally accept noncanonical LZ4-method blocks where `compressedLen >= originalLen`, but no canonical writer found produces them. Impact Applications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputStream` can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload. Patch As of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new `acceptOversizedBlocks` flag to restore the old behavior, but this reintroduces the DoS vector.