CVE-2026-59949

Summary

Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.

This affects applications where an attacker can influence the byte array object or the off / len arguments passed to affected XXHash APIs. It does not affect the common case where only the contents of a valid byte array are attacker-controlled.

Java-based XXHash implementations are not affected.

Details

The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:

• XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)
• XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)
• XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)
• XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)

Before the fix, the streaming JNI implementations did not validate bytes, off, or len before calling XXHashJNI.XXH32_update / XXHashJNI.XXH64_update. The non-streaming JNI implementations called SafeUtils.checkRange, but SafeUtils.checkRange(byte[], int, int) skipped all array access when len == 0, so a null byte array with a zero length could still reach JNI.

As a result:

• hash(null, 0, 0, seed) and update(null, 0, 0) could pass a null array reference to JNI, causing a fatal JVM crash in GetPrimitiveArrayCritical.
• update(new byte[16], 0, Integer.MAX_VALUE) could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.

The oversized-length non-streaming hash(new byte[16], 0, Integer.MAX_VALUE, seed) case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.

The impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.

Mitigation

lz4-java 1.11.1 fixes this issue without requiring changes in user code.

If you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that off and len describe a range fully contained in the array before calling native XXHash methods.

Using XXHashFactory.safeInstance() avoids the JNI boundary and is not affected by this native crash behavior.

LZ4 compression for Java, based on Yann Collet's work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4): ° low memory footprint (~ 16 KB), ° very fast (fast scan with skipping heuristics in case the input looks incompressible), ° reasonable compression ratio (depending on the redundancy of the input). * high compression (LZ4 HC): ° medium memory footprint (~ 256 KB), ° rather slow (~ 10 times slower than LZ4), ° good compression ratio (depending on the size and the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.

Security Fix(es):

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)

LZ4 compression for Java, based on Yann Collet's work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4): ° low memory footprint (~ 16 KB), ° very fast (fast scan with skipping heuristics in case the input looks incompressible), ° reasonable compression ratio (depending on the redundancy of the input). * high compression (LZ4 HC): ° medium memory footprint (~ 256 KB), ° rather slow (~ 10 times slower than LZ4), ° good compression ratio (depending on the size and the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.

Security Fix(es):

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)

LZ4 compression for Java, based on Yann Collet's work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4): ° low memory footprint (~ 16 KB), ° very fast (fast scan with skipping heuristics in case the input looks incompressible), ° reasonable compression ratio (depending on the redundancy of the input). * high compression (LZ4 HC): ° medium memory footprint (~ 256 KB), ° rather slow (~ 10 times slower than LZ4), ° good compression ratio (depending on the size and the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.

Security Fix(es):

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.

TuxCare rebuilt org.lz4:lz4-java to address 1 CVE. Fixed in 1.8.0-tuxcare.2.