From $URL : A denial of service flaw was found in the Murmur hash function implementation, as being used by various Java implementations. A specially-crafted set of keys could trigger Murmur hash function collisions, which degrade hash table items insert performance by changing hash table operations complexity from an expected/average O(n) to the worst case O(n^2). Reporters were able to find colliding strings efficiently using equivalent substrings. As various web application frameworks for Java automatically pre-fill certain arrays with data from the HTTP request (such as GET or POST parameters) for Java web applications, a remote attacker could use this flaw to make the Java virtual machine to use an excessive amount of CPU time by sending a POST request with a large number parameters which hash to the same value. A different vulnerability than CVE-2012-2739. References: [1] http://www.openwall.com/lists/oss-security/2012/11/23/4 [2] http://www.ocert.org/advisories/ocert-2012-001.html [3] http://2012.appsec-forum.ch/conferences/#c17 [4] https://www.131002.net/data/talks/appsec12_slides.pdf [5] http://asfws12.files.wordpress.com/2012/11/asfws2012-jean_philippe_aumasson-martin_bosslet-hash_flooding_dos_reloaded.pdf
CVE-2012-5373 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-5373): Oracle Java SE 7 and earlier, and OpenJDK 7 and earlier, computes hash values without properly restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table, as demonstrated by a universal multicollision attack against the MurmurHash3 algorithm, a different vulnerability than CVE-2012-2739.
dev-java/sun-{jdk,jre-bin} and app-emul/emul-linux-x86-java have gone. dev-java/oracle-{jdk,jre}-bin were updated beyond 7u7 ages ago. It's really too late to issue a GLSA report about it now.
