https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 11:20:19 +0000 https://vulnerability.circl.lu/vuln/ghsa-xx22-p4ch-683r <p><strong>Affected:</strong> Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java</p> <p>### Summary</p> <p>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.</p> <p>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.</p> <p>Java-based XXHash implementations are *not* affected.</p> <p>### Details</p> <p>The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:</p> <p>- `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)`</p> <p>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.</p> <p>As a result:</p> <p>- `hash(null, 0, 0, seed)` and `update(null…</p> <p><strong>Affected:</strong> Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java</p> <p>### Summary</p> <p>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.</p> <p>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.</p> <p>Java-based XXHash implementations are *not* affected.</p> <p>### Details</p> <p>The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:</p> <p>- `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)`</p> <p>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.</p> <p>As a result:</p> <p>- `hash(null, 0, 0, seed)` and `update(null…</p> https://vulnerability.circl.lu/vuln/ghsa-xx22-p4ch-683r