It was discovered that the Libraries component did not properly handle method invocations with an exhausted rank. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

Oracle Java SE 6u81, 7u65 and 8u11 fixes an unspecified vulnerability in the Deployment component (CVE-2014-4227). Upstream has CVSSv2 scored this issue as: 10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA

Florian Weimer discovered that AtomicReferenceFieldUpdater in OpenJDK does not properly check if the field to be updated is of primitive type. An untrusted Java application or applet could use flaw to trigger Java virtual machine memory corruption and possibly bypass Java sandbox restrictions.

AtomicReferenceFieldUpdater API documentation: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.html

This issue is mitigated by the bug that prevents AtomicFieldUpdater instances when code runs under security manager restrictions under OpenJDK and Oracle JDK 6 and 7. The bug was fixed in JDK8:

http://bugs.java.com/bugdatabase/viewbug.do?bugid=7103570 http://bugs.java.com/bugdatabase/viewbug.do?bugid=7131655 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965

Acknowledgement:

This issue was discovered by Florian Weimer of Red Hat Product Security.

It was discovered that the bytecode verification did not properly prevent ctor calls to this() and super() from certain code constructs. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that the Hotspot component did not properly parse invalid generic attributes for fields and methods. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.