About Memory Leak of kinit with pkinit Plugin

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

About Memory Leak of kinit with pkinit Plugin

Zhou Yang
Dear Team,

I'm trying to transplant kinit (for AS, the lastest version *1.12.2*) into
a daemon program. But when I tested the stability of this feature (by
infinite loop), a memory leak problem was found. And there're some clues
below which may be helpful:

1. When I remove "*pkinit.so*", there will not be memory leak. So I guess
the problem is only associated with pkinit plugin.

2. I also tried to use *valgrind *to locate the problem (both my program
and standard kinit). And the main report is below:
        $valgrind kinit *username *(and then type the password)
                          ...

* 57,328 (176 direct, 57,152 indirect) bytes in 1 blocks are definitely
lost in loss record 568 of 568*

*    at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)*

*    by 0x6842D32: ???*

*    by 0x68C88EF: ???*

*    by 0x68CADD6: ???*

*    by 0x68CB0CB: ???*

*    by 0x68CAB0A: ???*

*    by 0x68CB34F: ???*

*    by 0x68CC3D8: ???*

*    by 0x65D0E00: ???*

*    by 0x65CAEB3: ???*

*    by 0x65C6D77: ???*

*    by 0x50DC9C9: k5_init_preauth_context (preauth2.c:154)*

    Here, the "*???*" in the middle may be derived from dlopen-ing shared
object, and I can't trace it deeply.

Would you please fix it ASAP? Thanks.

Best Regards,

Sherice
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About Memory Leak of kinit with pkinit Plugin

Greg Hudson
On 09/22/2014 04:17 AM, Zhou Yang wrote:
> I'm trying to transplant kinit (for AS, the lastest version *1.12.2*) into
> a daemon program. But when I tested the stability of this feature (by
> infinite loop), a memory leak problem was found.
[...]
> * 57,328 (176 direct, 57,152 indirect) bytes in 1 blocks are definitely
> lost in loss record 568 of 568*

I believe you are seeing heap memory which is allocated by OpenSSL
during initialization and never cleaned up.  valgrind detects it as
leaked because the OpenSSL library has been unloaded by the time the
process exits.

We cannot currently tell OpenSSL to clean up its heap memory, because we
cannot know whether OpenSSL is being used by the application or by
another library.

This only becomes an unbounded memory leak if the PKINIT module (and
therefore OpenSSL) is repeatedly loaded and unloaded as a result of the
application's krb5 usage.  If the application uses the same krb5_context
for all AS-REQs, or is itself linked against OpenSSL, there won't be an
unbounded leak.

In 1.13 (due out soon) we open plugin modules with RTLD_NODELETE where
available, which precludes this repeated load-unload scenario and can
also improve performance.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About Memory Leak of kinit with pkinit Plugin

Russ Allbery-2
In reply to this post by Zhou Yang
Zhou Yang <[hidden email]> writes:

> 2. I also tried to use *valgrind *to locate the problem (both my program
> and standard kinit). And the main report is below:
>         $valgrind kinit *username *(and then type the password)
>                           ...

I use the following suppression file for checking any Kerberos
application, which hides various one-time allocations from MIT or Heimdal
(as well as hiding a few old memory leak bugs, but those were all small,
if I recall correctly, and already fixed in current versions).

This is probably specific to Linux in at least a few respects.

# -*- conf -*-
#
# This is a valgrind suppression file for analysis of test suite results.
#
# Suppress a variety of apparent memory leaks in various Kerberos
# implementations due to one-time instantiation of data, and a few other
# artifacts of the test suite for rra-c-util portability and utility code
# and related software.
#
# The canonical version of this file is maintained in the rra-c-util package,
# which can be found at <http://www.eyrie.org/~eagle/software/rra-c-util/>.
#
# Written by Russ Allbery <[hidden email]>
# Copyright 2011, 2012, 2013, 2014
#     The Board of Trustees of the Leland Stanford Junior University
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.

{
   dlopen-dlerror
   Memcheck:Leak
   fun:calloc
   fun:_dlerror_run
}
{
   heimdal-gss-config
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_config_parse_debug
}
{
   heimdal-gss-config-2
   Memcheck:Leak
   fun:*alloc
   fun:_krb5_config_get_entry
}
{
   heimdal-gss-krb5-init
   Memcheck:Leak
   fun:*alloc
   ...
   fun:_gsskrb5_init
}
{
   heimdal-gss-load-mech
   Memcheck:Leak
   fun:*alloc
   ...
   fun:_gss_load_mech
}
{
   heimdal-krb5-init-context-once
   Memcheck:Leak
   fun:*alloc
   ...
   fun:init_context_once
}
{
   heimdal-krb5-reg-plugins-once
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_plugin_register
   fun:reg_def_plugins_once
}
{
   heimdal-krb5-openssl-init
   Memcheck:Leak
   fun:*alloc
   obj:*
   fun:CRYPTO_*alloc
}
{
   mit-gss-ccache
   Memcheck:Leak
   fun:*alloc
   fun:krb5int_setspecific
   fun:kg_set_ccache_name
   fun:gss_krb5int_ccache_name
}
{
   mit-gss-ccache-2
   Memcheck:Leak
   fun:*alloc
   fun:strdup
   fun:kg_set_ccache_name
   fun:gss_krb5int_ccache_name
}
{
   mit-gss-error
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_gss_save_error_string
}
{
   mit-krb5-pkinit-openssl-init
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_init_preauth_context
}
{
   mit-krb5-pkinit-openssl-request
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_preauth_request_context_init
}
{
   mit-krb5-plugin-dirs
   Memcheck:Leak
   fun:calloc
   fun:krb5int_open_plugin_dirs
}
{
   mit-krb5-plugin-dlerror
   Memcheck:Leak
   fun:calloc
   fun:_dlerror_run
   ...
   fun:krb5int_open_plugin
}
{
   mit-krb5-plugin-register
   Memcheck:Leak
   fun:malloc
   fun:strdup
   fun:register_module.isra.1
}

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About Memory Leak of kinit with pkinit Plugin

Simo Sorce-3
In reply to this post by Greg Hudson
On Mon, 22 Sep 2014 11:56:56 -0400
Greg Hudson <[hidden email]> wrote:

> On 09/22/2014 04:17 AM, Zhou Yang wrote:
> > I'm trying to transplant kinit (for AS, the lastest version
> > *1.12.2*) into a daemon program. But when I tested the stability of
> > this feature (by infinite loop), a memory leak problem was found.
> [...]
> > * 57,328 (176 direct, 57,152 indirect) bytes in 1 blocks are
> > definitely lost in loss record 568 of 568*
>
> I believe you are seeing heap memory which is allocated by OpenSSL
> during initialization and never cleaned up.  valgrind detects it as
> leaked because the OpenSSL library has been unloaded by the time the
> process exits.
>
> We cannot currently tell OpenSSL to clean up its heap memory, because
> we cannot know whether OpenSSL is being used by the application or by
> another library.
>
> This only becomes an unbounded memory leak if the PKINIT module (and
> therefore OpenSSL) is repeatedly loaded and unloaded as a result of
> the application's krb5 usage.  If the application uses the same
> krb5_context for all AS-REQs, or is itself linked against OpenSSL,
> there won't be an unbounded leak.
>
> In 1.13 (due out soon) we open plugin modules with RTLD_NODELETE where
> available, which precludes this repeated load-unload scenario and can
> also improve performance.

PAM modules are loaded and unloaded at each use, I wonder if this will
causes issues (or merely keep the leak in check) in pam_krb5 when
pkinit is configured.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About Memory Leak of kinit with pkinit Plugin

Russ Allbery-2
Simo Sorce <[hidden email]> writes:

> PAM modules are loaded and unloaded at each use, I wonder if this will
> causes issues (or merely keep the leak in check) in pam_krb5 when pkinit
> is configured.

Yes, pam_krb5 with MIT Kerberos and OpenSSL and the PKINIT module
installed does leak memory, I believe.  I've been worried about that for a
while.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev