Peter Shipton

**Name of the Vulnerable Software and Affected Versions** Eclipse Openj9 versions prior to 0.32.0 **Description** The issue arises when Java 8 and 11 fail to throw an exception captured during bytecode verification triggered by a MethodHandle invocation. This allows unverified methods to be invoked using MethodHandles. **Recommendations** For Eclipse Openj9 versions prior to 0.32.0, update to version 0.32.0 or later to resolve the issue. As a temporary workaround, consider restricting the use of MethodHandles to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Eclipse Openj9 versions prior to 0.29.0 **Description** The issue is related to the JVM not throwing IllegalAccessError for MethodHandles that invoke inaccessible interface methods. This could potentially allow an attacker to obtain sensitive information, resulting in a low confidentiality impact. **Recommendations** For Eclipse Openj9 versions prior to 0.29.0, update to version 0.29.0 or later to resolve the issue. As a temporary workaround, consider restricting access to MethodHandles that invoke interface methods to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions up to and including 0.23 **Description** The issue is related to errors in handling UTF-8 encoded data. It may allow a remote attacker to execute arbitrary code. The problem occurs when the virtual machine or JNI natives are converting from UTF-8 characters to platform encoding, potentially leading to a stack-based buffer overflow. **Recommendations** For Eclipse OpenJ9 versions up to and including 0.23, consider disabling the UTF-8 conversion functionality until a patch is available. Restrict access to the virtual machine or JNI natives to minimize the risk of exploitation. Avoid using the `UTF-8` encoding in the affected virtual machine or JNI natives until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions prior to 0.21 **Description** The issue arises when the System.arraycopy method is called with a length that exceeds the length of the source or destination array, potentially causing the method to return prematurely with an undefined value. This can lead to the use of any value present in the return register at that time, as if it matches the method's declared return type. The problem is specifically noted in certain specially crafted code patterns on Power platforms. **Recommendations** For Eclipse OpenJ9 versions prior to 0.21, consider avoiding the use of the System.arraycopy method with lengths that could exceed the array bounds until a fixed version is available. As a temporary workaround, implement input validation to ensure that the length passed to System.arraycopy does not exceed the length of the source or destination array. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions 0.15 through 0.16 **Description** The issue is related to errors in access control to diagnostic operations in the Eclipse OpenJ9 virtual machine. This could allow a remote attacker to elevate their privileges. The vulnerability may also cause a denial of service, resulting in low availability impact. **Recommendations** For Eclipse OpenJ9 versions 0.15 through 0.16, consider restricting access to diagnostic operations such as causing a GC or creating a diagnostic file until a patch is available. As a temporary workaround, implement privilege checks for these operations to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions prior to 0.15 **Description** The issue is related to synchronization errors when using shared resources, which can lead to a "race condition" situation. This can cause memory corruption. Additionally, there is a problem with the loop versioner failing to privatize a value pulled out of the loop, potentially resulting in issues such as reading out of array bounds. The vulnerability could also allow a local attacker to gain elevated privileges on the system by injecting code due to unused RPATHS in AIX builds. **Recommendations** For Eclipse OpenJ9 versions prior to 0.15, update to version 0.15 or later to resolve the issue. As a temporary workaround, consider restricting access to shared resources to minimize the risk of exploitation. Avoid using the loop versioner with conditions that read fields and are moved out of the loop until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions prior to 0.15 **Description** The issue is related to the String.getBytes(int, int, byte[], int) method in Eclipse OpenJ9, which does not verify that the provided byte array is non-null nor that the provided index is in bounds when compiled by the JIT. This allows arbitrary writes to any 32-bit address or beyond the end of a byte array within Java code run under a SecurityManager. The vulnerability is also associated with a buffer overflow, which could allow a remote attacker to execute arbitrary code. **Recommendations** For Eclipse OpenJ9 versions prior to 0.15, update to version 0.15 or later to resolve the issue. As a temporary workaround, consider restricting the use of the String.getBytes(int, int, byte[], int) method until a patch is available. Additionally, ensure that all code run under a SecurityManager is thoroughly reviewed and validated to prevent potential exploitation.

**Name of the Vulnerable Software and Affected Versions** OpenJDK + Eclipse OpenJ9 version 0.11.0 **Description** The issue concerns the public jdk.crypto.jniprovider.NativeCrypto class in OpenJDK + Eclipse OpenJ9, which contains public static natives that accept pointer values. These pointer values are dereferenced in the native code, potentially leading to issues. **Recommendations** For OpenJDK + Eclipse OpenJ9 version 0.11.0, consider restricting access to the `jdk.crypto.jniprovider.NativeCrypto` class until a patch is available. As a temporary workaround, avoid using the public static natives in this class to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.