Bug#1150247: lz4-java: CVE-2026-106449 CVE-2026-106450 CVE-2026-106451

[Salvatore Bonaccorso]

Source: lz4-java
Version: 1.11.2+ds1-3
X-Debbugs-CC: team at security.debian.org
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