Source: lz4-java Version: 1.11.2+ds1-3 X-Debbugs-CC: [email protected] Severity: important Tags: security upstream
Hi, The following vulnerabilities were published for lz4-java. CVE-2026-106449[0]: | 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. This issue is fixed in version | 1.11.4. CVE-2026-106450[1]: | yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, | net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 | MiB block buffers whenever a maximum-block-size frame header is | read, and the default concatenated-frame mode allows attacker- | controlled streams containing many minimal empty frames to trigger | roughly 8 MiB of allocation for every 11 input bytes. The stream | produces no decompressed output while consuming CPU and garbage- | collection time, so decompressed-size limits do not mitigate the | issue; readSingleFrame mode is not affected. This issue is fixed in | version 1.11.4. CVE-2026-106451[2]: | yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until | 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to | create an exclusive temporary .lck file but derives the native- | library path by removing the suffix, then FileOutputStream opens | that predictable path without exclusive creation, allowing another | local user with access to the same shared temporary directory to | create or replace the library file before System.load() uses it. | Successful exploitation depends on shared-directory permissions, | host protections, and winning the race, and can execute native code | as the victim; hardened systems may instead cause library loading to | fail and fall back to Java implementations. Configurations using a | system library, a private java.io.tmpdir, or Java-only | implementations are not affected. This issue is fixed in version | 1.11.4. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-106449 https://www.cve.org/CVERecord?id=CVE-2026-106449 [1] https://security-tracker.debian.org/tracker/CVE-2026-106450 https://www.cve.org/CVERecord?id=CVE-2026-106450 [2] https://security-tracker.debian.org/tracker/CVE-2026-106451 https://www.cve.org/CVERecord?id=CVE-2026-106451 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
