RFR 9044691: Memory leak in JceSecurity

Sean Mullan sean.mullan at oracle.com
Fri Oct 21 20:24:37 UTC 2016

Hi Bradley,

Thanks for filing the bug, and coming up with a potential patch for the 
issue. The bug has just made its way into our system, so we have not 
looked at it in detail yet, but in the meantime I added a link to your 
post as a comment. You can see the bug here: 


On 10/20/2016 01:06 PM, Bradley Hess wrote:
> I posted an issue (assigned ID # 90444691) using the public facing bug
> submission page, as I don't have an OpenJDK account.
> There's a slow memory leak in JceSecurity.  The original source uses an
> IdentityHashMap, which I believe is done to avoid a case where a trusted
> Provider has a bad implementation of hashCode/equals that a rogue
> Provider is able to mimic in order to avoid verification.
> In my patch, I change the map to be a WeakHashMap<Class<? extends
> Provider>, Object>, which I believe provides the same guarantees (that a
> Provider class has actually been validated) without leaking memory.
> This also provides an additional optimization: new instances of a
> previously-verified provider class do not cause the CodeSource to be
> re-verified.
> Attached is a patch that I believe addresses this issue.
> Cheers,
> Brad

More information about the security-dev mailing list