Discussion:
RFR 9044691: Memory leak in JceSecurity
Bradley Hess
2016-10-20 17:06:36 UTC
Permalink
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
Sean Mullan
2016-10-21 20:24:37 UTC
Permalink
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:
https://bugs.openjdk.java.net/browse/JDK-8168469

--Sean
Post by Bradley Hess
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
Loading...