GHSA-xx22-p4ch-683r

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...