Zstd-jni Negative Offset Bounds Check Bypass (GHSA-rm53-6wr5-t3xm)

Zstd-jni Negative Offset Out-of-Bounds Check Bypass Vulnerability (GHSA-rm53-6wr5-t3xm) Vulnerability Overview Vulnerability Name: The bounds check in can be bypassed using a negative offset Severity: Medium (CVSS 3.1: 5.5, CVSS 4.0: 5.1/10) CWE: CWE-130 (Out-of-bounds read leads to a security vulnerability) Root Cause: only checks the upper bound of ( ) but does not check the lower bound. When a negative is passed in, the condition may evaluate to true unconditionally, thereby bypassing the check. This causes the underlying C function to read unmapped memory at a negative offset, leading to a crash. Impact: Applications that parse attacker-supplied compressed frames and pass an attacker-controllable offset will crash on a 32-bit JVM (DoS); no information disclosure or code execution has been observed to date. Scope of Impact Affected Versions: 1.5.7–1.5.13 Fixed Versions: 1.5.7–14 Affected Package: (github.com/luben/zstd-jni) Trigger Conditions: A negative is passed via the public API , bypassing the Java-layer check and entering the native code , resulting in a crash on a 32-bit JVM. POC / Exploit Code Reproduction commands: Crash stack trace (key frames): Fix Adopt the same "subtraction"-based check pattern used in , validating the lower bound simultaneously: Key Points of the Fix: 1. Add a lower-bound check for in . 2. Change the validation to (subtraction form), maintaining consistency with . 3. For deprecated APIs such as / , it is recommended to validate uniformly within , rather than unconditionally trusting the Java-side bounds checks.

Goal Reached Thanks to every supporter — we hit 100%!

Zstd-jni Negative Offset Bounds Check Bypass (GHSA-rm53-6wr5-t3xm)

More from this source