The vulnerability lies in the core decompression logic of the pure Java LZ4 decompressors provided by the yawkat/lz4-java library. The issue stems from improper handling of a specific case in the LZ4 compression format where a 'match' operation has a distance of zero. In the vulnerable versions, this would cause the decompressor to copy bytes from a part of the output buffer that hadn't been written to yet during the current decompression operation.
If an application reuses its decompression buffers without clearing them between uses, this flaw could be exploited. An attacker could craft a special compressed data stream that, when decompressed, would cause the library to copy leftover data from the previous use of the buffer into the new decompressed output. This leftover data could be sensitive information, leading to an information leak.
The patch addresses this by modifying the shared decompression logic, which is defined in the src/build/source_templates/decompress.template file. This template is used to generate the decompress methods for the LZ4JavaSafeDecompressor and LZ4JavaUnsafeDecompressor classes. The fix introduces a check for matchDec == 0. When this condition is met, instead of performing a copy, it calls a new LZ4Utils.zero utility function to fill the relevant portion of the output buffer with zeros, effectively preventing the information leak. The analysis of the patch commit confirms that these are the key changes and the functions involved.
net.jpountz.lz4.LZ4JavaSafeDecompressor.decompresssrc/build/source_templates/decompress.template
net.jpountz.lz4.LZ4JavaUnsafeDecompressor.decompresssrc/build/source_templates/decompress.template
net.jpountz.lz4.LZ4Utils.zerosrc/java/net/jpountz/lz4/LZ4Utils.java
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| at.yawk.lz4:lz4-java | maven | <= 1.10.0 | 1.10.1 |
| org.lz4:lz4-java | maven | <= 1.8.1 | |
| org.lz4:lz4-pure-java | maven | <= 1.8.1 | |
| net.jpountz.lz4:lz4 | maven | <= 1.8.1 |