[krbdev.mit.edu #5941] memory leak in gss_accept_sec_context api

sharma via RT rt-comment at krbdev.mit.edu
Thu Apr 17 22:12:23 EDT 2008


==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 

 

1.	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.

 

2.	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.

 

SAM SHARMA





More information about the krb5-bugs mailing list