blake3: validate bounds and check null pointers in JNI - Fixes #31026 - #31027
blake3: validate bounds and check null pointers in JNI - Fixes #31026#31027tommymh wants to merge 1 commit into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
@google-cla I signed it!
|
bb44f50 to
8a9b4ad
Compare
In blake3_jni.cc, the JNI methods implementing BLAKE3 hashing did not validate the offset or input_len / out_len parameters against the underlying Java array lengths, nor did they check the pointers returned by GetPrimitiveArrayCritical for NULL.
As a result, calling Blake3MessageDigest.engineUpdate directly with invalid bounds (such as a negative length or an offset outside array boundaries) causes unchecked pointer arithmetic while the array is pinned, resulting in a native SIGSEGV inside libunix_jni.so.
While typical callers using the public java.security.MessageDigest.update pass through standard Java bounds checks, direct callers of engineUpdate (or native callers) could trigger undefined behavior and abort the JVM process.
Changes:
Java Layer (Blake3MessageDigest.java):
- Added explicit bounds and null checks in engineUpdate(byte[] data, int offset, int length).
- Throws NullPointerException if data == null and IndexOutOfBoundsException if offset < 0, length < 0, or offset + length > data.length.
Native Layer (src/main/native/blake3_jni.cc):
- Added defensive bounds validation using env->GetArrayLength() in blake3_hasher_update and blake3_hasher_finalize.
- Throws java/lang/ArrayIndexOutOfBoundsException via JNI if the bounds are invalid.
- Added nullptr checks on pointers returned by GetPrimitiveArrayCritical before dereferencing or performing pointer arithmetic.
- Ensures pinned arrays are safely released in the event of an inner allocation failure.
Verified using a reproducer calling engineUpdate(data, 0, -1):
Before: Native SIGSEGV crash.
After: Clean java.lang.IndexOutOfBoundsException thrown.
Ran existing tests covering BLAKE3 digest functionality to ensure normal hashing paths are unaffected.