|Date:||Wed, 16 Apr 2008 18:04:19 -0700|
|From:||sam sharma <email@example.com>|
|Subject:||memory leak in gss_accept_sec_context api|
==6940== 101 (40 direct, 61 indirect) bytes in 1 blocks are definitely lost in loss record 77 of 146
==6940== at 0x4904DEB: malloc (vg_replace_malloc.c:207)
==6940== by 0x54C6E19: gssint_convert_name_to_union_name (g_glue.c:468)
==6940== by 0x54C3DAB: gss_accept_sec_context (g_accept_sec_context.c:304)
==6940== by 0x5949F17: ???
==6940== by 0x5949234: ???
I analyzed the gss_accept_sec_context() code and came to conclusion that
- first time: tmp_src_name hold an allocated buffer pointer from gssint_convert_name_to_union_name() and assign to the *src_name variable.
I think tmp_src_name variable should be initialized to NULL here after assigning the value of tmp_src_name variable value to *src_name variable so that later on it is not freed.
- second time: tmp_src_name hold an allocated buffer pointer from gssint_convert_name_to_union_name() and used in gss_display_name().
This time tmp_src_name buffer is freed only ‘if (src_name == NULL && tmp_src_name != NULL)’ is true. I think tmp_src_name should be always freed it is not null and the if condition will look like ‘if (tmp_src_name != NULL) gss_release_name(…).
Some adjustments in code can get rid of this memory leak. I am using krb5 1.6.3 source code. I will check if it already fixed in 1.6.4 beta code.