RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl

Weijun Wang weijun at openjdk.org
Thu Mar 9 14:12:49 UTC 2023


On Thu, 9 Mar 2023 08:21:15 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> @dfunch, @djelinski, @wangweij Thank you a lot for review and suggestions.
> The customer uses its own native Kerberos provider. This provider can allocate up to 2 MB of native memory per GSSContext until they are disposed. An application can generate many contexts quickly and they are not cleaned up until GC collects them. It causes high native memory consumption. So, the main idea of the fix is to dispose context as soon as possible.
> Unfortunately, in most cases, context is not yet established in the `NegotiatorImpl::init` method after `initSecContext()`. So, we have no right place in the `NegotiatorImpl` to dispose the context after `NegotiatorImpl::init`. This is the reason I have to move the initiation of context dispose into the `HttpURLConnection`.
> `sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests can be used to verify that `NegotiatorImpl::disposeContext()` is called correctly.

> @alexeybakhtin thanks for adding more context. I believe @wangweij was suggesting adding `context.dispose()` after `initSecContext` in `NegotiatorImpl::nextToken`, which indeed looks like the right thing to do.

Yes, after both `initSecContext` calls. In either case it's possible the context has already been established.

-------------

PR: https://git.openjdk.org/jdk/pull/12920



More information about the security-dev mailing list