JDK-8063700 : -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests in SunPKCS11
  • Type: Bug
  • Component: security-libs
  • Affected Version: 8u40,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • CPU: generic
  • Submitted: 2014-11-06
  • Updated: 2017-10-16
  • Resolved: 2014-11-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u171Fixed 8u40Fixed 9 b40Fixed
Description
Changes introduced by JDK-6311046 resulted in failures in many JCK api/javax_crypto tests.  BaddPaddingExceptions and InvalidKeyExceptions are thrown with the same message of "Invalid pad value".   The failure occurs only with SunPKCS11 provider, which is default on Solaris installs.  It can occur on other OSes if SunPKCS11 is enabled.

java.security.InvalidKeyException: Invalid pad value!
        at javax.crypto.SealedObject.getObject(SealedObject.java:355)
        at javasoft.sqe.tests.api.javax.crypto.SealedObject.getObject4Tests.getObject4Tests0001(getObject4Tests.java:125)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        ...


The following tests that threw exceptions causing a failure are:
api/javax_crypto/Cipher/index_doFinal1Tests 
api/javax_crypto/Cipher/index_doFinal2Tests 
api/javax_crypto/Cipher/index_doFinal3Tests 
api/javax_crypto/Cipher/index_doFinal4Tests 
api/javax_crypto/Cipher/index_init1Tests 
api/javax_crypto/Cipher/index_init2Tests 
api/javax_crypto/Cipher/index_update1Tests 
api/javax_crypto/Cipher/index_update2Tests 
api/javax_crypto/CipherInputStream/index2_read5 
api/javax_crypto/CipherInputStream/index_read1Tests 
api/javax_crypto/CipherInputStream/index_read2Tests 
api/javax_crypto/CipherInputStream/index_read3Tests 
api/javax_crypto/CipherOutputStream/index_flushTests 
api/javax_crypto/CipherOutputStream/index_write1Tests 
api/javax_crypto/CipherOutputStream/index_write2Tests 
api/javax_crypto/CipherOutputStream/index_write3Tests 
api/javax_crypto/SealedObject/index2_getObject4 
api/javax_crypto/SealedObject/index_getObject1Tests 
api/javax_crypto/SealedObject/index_getObject2Tests 
api/javax_crypto/SealedObject/index_getObject3Tests
Comments
All JCK api/javax_crypto tests passed with -Xcheck:jni tested on Solaris sparc (sc11152570.us.oracle.com) and Windows( sca00jir.us.oracle.com).
16-10-2017
David Simms added a comment - 2014-11-06 04:07 --------------------------------------------------------------------- So I suspect p11_crypt.c use of JNI ReleasePrimitiveArrayCritical() is slightly incorrect when using -Xcheck:jni: Normally GetPrimitiveArrayCritical returns a direct heap pointer, and release only serves to re-enable GC JDK-6311046 forces a copy of the buffer (wrapping with bounds checking bytes), requiring ReleasePrimitiveArrayCritical() to use "mode=JNI_COMMIT" to make any actual changes back in the Java array. p11_crypt.c (and perhaps more code) unconditionally uses JNI_ABORT (i.e. release resources but do not update the Java Array). This may work fine without -Xcheck:jni.
06-11-2014