An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.
External References:
https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7
Upstream patch:
https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb
CVE assignment:
http://seclists.org/oss-sec/2016/q4/602
An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.
Eclipse OpenJ9 could allow a local attacker to gain elevated privileges on the system, caused by the failure to performs an authorization check when an actor attempts to access a resource or perform an action. An attacker could exploit this vulnerability to gain access to diagnostic operations such as causing a GC or creating a diagnostic file.
It was discovered that the Scripting component of OpenJDK did not properly restrict access to scripting engine via Global object's engine variable when using Security Manager or class filtering. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.
An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.
It was discovered that the JNDI comment of OpenJDK did not properly enforce the restriction controlled by the com.sun.jndi.ldap.object.trustURLCodebase system property. In certain cases, a Java LDAP client could unexpectedly load and execute code form an LDAP server.
It was discovered that the Hotspot component of OpenJDK did not perform access checks correctly in certain cases when performing field link resolution. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the LDAPCertStore class in the JNDI component of OpenJDK failed to securely handle LDAP referrals. An attacker could possibly use this flaw to make the LDAPCertStore fetch attacker-controlled certificate data.
A out of bounds access flaw was found in the font layout engine in the 2D component of OpenJDK. Missing validation of the position value in GlyphIterator::setCurrGlyphID could lead to memory corruption, triggered by a specially crafted font file. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
Last updated 25 August 2025
It was discovered that the Security component of OpenJDK did not restrict which classes could be used when deserializing keys form the JCEKS key stores. A specially crafted JCEKS key store could possibly use this flaw to execute arbitrary code with the privileges of an application reading data form the key store.
The fix adds support for a new security property jceks.key.serialFilter which can be used to specify classes that can be used when deserializing data from the JCEKS key stores.
A flaw was found in the BigDecimal implementation in the Libraries component of OpenJDK. An untrusted numeric value parsed by a Java application could the application to use an excessive amount of CPU time.
It was discovered that the JMX component of OpenJDK failed to properly set the deserialization filter for the SingleEntryRegistry in certain cases. A remote attacker could possibly use this flaw to bypass intended deserialization restrictions.
An out-of-bounds read in cmstypes.c in TypeMLURead function was found, leading to heap memory leak triggered by crafted ICC profile.
Upstream patch:
https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2
CVE request:
http://seclists.org/oss-sec/2016/q3/288
Last updated 25 August 2025
An issue was discovered in libjpeg 9a and 9d. The allocsarray function in jmemmgr.c allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted file.
A use-after-free flaw was found in the way the AWT component of OpenJDK performed loading of the GTK library. An untrusted Java application or applet could use this flaw to possibly bypass certain Java sandbox restrictions.
A flaw was found in the RMI registry implementation in the RMI component of OpenJDK. Incorrect handling of the server-side dispatch could lead to selection of an incorrect skeleton class.
Oracle Java SE 6u201, 7u191, 8u181, and 10.0.2 fixes an unspecified vulnerability in the JSSE component (CVE-2018-2973). Upstream has CVSS scored this issue as: 5.9/CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixJAVA
It was discovered that the DHKeyAgreement and P11KeyAgreement implementations in the JCE component of OpenJDK did not guarantee sufficient strength of used keys to adequately protect generated shared secret. This could make it easier to break encryption by attacking key agreement rather than the encryption using the negotiated key.
The patch for this issue causes classes' method generateSecret(String algorithm) to fail unless it's call for "TlsPremasterSecret", or the "jdk.crypto.KeyAgreement.legacyKDF" system property is set to true.
It was found that Satellite 5 configured with SSL/TLS for the PostgreSQL backend failed to correctly validate X.509 server certificate host name fields. A man-in-the-middle attacker could use this flaw to spoof a PostgreSQL server using a specially crafted X.509 certificate.
A certificate verification flaw was found in the JSSE component of OpenJDK. No check was preformed during the TLS session resumption to ensure that the same endpoint identification algorithm had been used when originally opening the session as was required when resuming the session. In certain cases, this could lead to having TLS connection established without required server identity verification.
A use-after-free vulnerability was discovered in the pngimagefree function in the libpng library. This could lead to denial of service or a potentially exploitable crash when a malformed image is processed.
An infinite loop flaw was found in the RIFF (Resource Interchange File Format) file format reader in the Sound component of OpenJDK. A specially crafted RIFF file could cause a Java application to enter an infinite loop while reading the RIFF file.
It was discovered that the implementation of the NamedNodeMapImpl class in the JAXP component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that deserialization of multiple classes in the Security component of OpenJDK did not properly ensure consistency of the instances created form the serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the implementation of the PriorityBlockingQueue class in the Concurrency component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the implementation of the Container class in the AWT component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the implementation of the TabularDataSupport class in the JMX component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.