RLSA-2022:5726

The java-17-openjdk packages provide the OpenJDK 17 Java Runtime Environment and the OpenJDK 17 Java Software Development Kit.

The following packages have been upgraded to a later upstream version: java-17-openjdk (17.0.4.0.8). (BZ#2084650)

Security Fix(es):

• OpenJDK: integer truncation issue in Xalan-J (JAXP, 8285407) (CVE-2022-34169)

• OpenJDK: class compilation issue (Hotspot, 8281859) (CVE-2022-21540)

• OpenJDK: improper restriction of MethodHandle.invokeBasic() (Hotspot, 8281866) (CVE-2022-21541)

• OpenJDK: random exponentials issue (Libraries, 8283875) (CVE-2022-21549)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Bug Fix(es):

• Previous Rocky Enterprise Software Foundation builds of OpenJDK 17 altered the arguments passed to sun.security.pkcs11.wrapper.PKCS11.getInstance() in order to facilitate FIPS support. This build adds an additional form of the method, retaining the original arguments, so that applications which depend on this internal method continue to function with Rocky Enterprise Software Foundation builds of OpenJDK. (BZ#2099913)

• With previous Rocky Enterprise Software Foundation builds of OpenJDK 17, Mac key generation and import would fail due to the lack of the CKA_SIGN attribute on the key. This attribute is now added as part of the NSS FIPS configuration. (BZ#2108190)

• With the release of Rocky Linux 8.6, a change was made so that disabling OpenJDK FIPS mode required the use of both the -Djava.security.disableSystemPropertiesFile=true and -Dcom.redhat.fips=false options, with the intention that FIPS mode could be controlled independently of system security properties. This change has now been reverted and only -Djava.security.disableSystemPropertiesFile=true is required to disable FIPS mode, as in Rocky Linux 8.4. (BZ#2108206)

• Previous Rocky Enterprise Software Foundation builds of OpenJDK 17 running in FIPS mode with a SecurityManager would fail due to a lack of module access permissions. This has now been corrected. (BZ#2108209)