[3132] in Kerberos-V5-bugs
krb5-libs/769: libkrb4 resource leak
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Thu Oct 7 09:59:09 1999
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, ghudson@MIT.EDU
Message-Id: <199910071358.JAA19585@rcn-sucks.fsck.com>
Date: Thu, 7 Oct 1999 09:58:12 -0400 (EDT)
From: ghudson@MIT.EDU
Reply-To: ghudson@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 769
>Category: krb5-libs
>Synopsis: rd_svc_key seems to have a resource leak
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Oct 07 09:59:01 EDT 1999
>Last-Modified:
>Originator: Greg Hudson
>Organization:
MIT
>Release: 1.0
>Environment:
System: NetBSD rcn-sucks.fsck.com 1.3.2 NetBSD 1.3.2 (ATHENA) #0: Mon Jun 22 17:32:46 EDT 1998 nathanw@antisnork.mit.edu:/u1/var/build/sys-1.3.2/arch/i386/compile/ATHENA i386
>Description:
When Ted committed revision 1.9 of rd_svc_key.c, he reorganized the
logic towards the end of krb54_get_service_keyblock(). As far as
I can tell, he introduced a resource leak: the krb5_kt_close() of
kt_id only happens in a particular error case, and not in the
success case.
>How-To-Repeat:
Read a service key lots of times and run out of file descriptors, I
guess.
>Fix:
I expect this would fix the problem.
Index: rd_svc_key.c
===================================================================
RCS file: /cvs/krbdev/krb5/src/lib/krb4/rd_svc_key.c,v
retrieving revision 1.10
diff -c -r1.10 rd_svc_key.c
*** rd_svc_key.c 1999/04/03 19:55:00 1.10
--- rd_svc_key.c 1999/10/07 13:57:34
***************
*** 194,199 ****
--- 194,200 ----
&kt_entry.key, keyblock);
krb5_kt_free_entry(krb5__krb4_context, &kt_entry);
+ krb5_kt_close(krb5__krb4_context, kt_id);
errout:
if (princ)
>Audit-Trail:
>Unformatted:
