CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
LOW
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
AI Score
Confidence
Low
EPSS
Percentile
31.4%
The java-17-openjdk packages provide the OpenJDK 17 Java Runtime Environment and the OpenJDK 17 Java Software Development Kit.
Security Fix(es):
OpenJDK: memory corruption issue on x86_64 with AVX-512 (8317121) (CVE-2023-22025)
OpenJDK: certificate path validation issue during client authentication (8309966) (CVE-2023-22081)
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):
Additional validity checks in the handling of Zip64 files, JDK-8302483, were introduced in the 11.0.20 release of OpenJDK, causing the use of some valid zip files to now fail with an error. This release, 11.0.20.1, allows for zero-length headers and additional padding produced by some Zip64 creation tools. With both releases, the checks can be disabled using -Djdk.util.zip.disableZip64ExtraFieldValidation=true. (RHBZ#2237180).
A maximum signature file size property, jdk.jar.maxSignatureFileSize, was introduced in the 11.0.20 release of OpenJDK by JDK-8300596, with a default of 8 MB. This default proved to be too small for some JAR files. This release, 11.0.20.1, increases it to 16 MB.
The /usr/bin/jfr alternative is now owned by the java-17-openjdk package (RHEL-13706)
The jcmd tool is now provided by the java-17-openjdk-headless package, rather than java-17-openjdk-devel, to make it more accessible (RHEL-13656)
Installing the same java-17-openjdk-headless package on two different systems resulted in distinct classes.jsa files getting generated. This was because the CDS archive was being generated by a post script action of the java-17-openjdk-headless package. This prevented the use of the dynamic dump feature, as the checksum in the archive would be different on each system. This is resolved in this release by using the .jsa files generated during the initial build. (RHEL-13172)