JDK-8225695 : 32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 8,11,13
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-06-13
  • Updated: 2020-08-28
  • Resolved: 2019-06-14
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 11 JDK 13 JDK 14 JDK 8 Other
11.0.6-oracleFixed 13 b26Fixed 14Fixed 8u241Fixed openjdk8u272Fixed
Related Reports
Relates :  
JDK-8080462 - Update SunPKCS11 provider with PKCS11 v2.40 support
Description
/home/shade/trunks/jdk-jdk/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c: In function 'Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism':
/home/shade/trunks/jdk-jdk/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c:99:28: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         freeCKMechanismPtr((CK_MECHANISM_PTR) ckpMechanism);
                            ^
cc1: all warnings being treated as errors
Comments
Fix request (8u) I'd like to request a backport of this fix, as 8u is affected by the bug after the backport of 8080462. Patch applies cleanly (modulo paths). No test regressions observed in the sun/security/pkcs11 category.
28-08-2020
Fix request (11u): Requesting backport of this item for Oracle 11.0.6 parity. It is a necessary follow up after JDK-8080462. Patch applies cleanly, no regressions observed.
11-11-2019
Right. Dropped the label.
14-06-2019
You don't need approval for P1-P3 bugs in RDP1, see http://openjdk.java.net/jeps/3 for more info.
13-06-2019
Important to get it into 13, jdk13-fix-request set.
13-06-2019
RFR: https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020202.html
13-06-2019
Better patch: http://cr.openjdk.java.net/~shade/8225695/webrev.01
13-06-2019
This fixes it, rather crudely: http://cr.openjdk.java.net/~shade/8225695/webrev.00 I am pretty sure format specifiers are still incorrect. Also, helper methods in pkcs11wrapper.h might help us here.
13-06-2019
We record native pointer as "long" here, which ends up in that freeMechanism(): http://hg.openjdk.java.net/jdk/jdk/rev/f492567244ab#l8.20 Probably want to do what unsafe.cpp/addr_from_java(jlong) does here: static inline void* addr_from_java(jlong addr) { // This assert fails in a variety of ways on 32-bit systems. // It is impossible to predict whether native code that converts // pointers to longs will sign-extend or zero-extend the addresses. //assert(addr == (uintptr_t)addr, "must not be odd high bits"); return (void*)(uintptr_t)addr; }
13-06-2019