[OpenAFS-devel] FW: memory leaks in krb524d.... (patch to fix)
Neulinger, Nathan
nneul@umr.edu
Fri, 9 Nov 2001 13:55:13 -0600
FYI, in case anyone is using krb524d to do AFS stuff and doesn't follow the
krbdev list. This patch is against krb5-current to fix a memory leak in
krb524d.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
-----Original Message-----
From: Neulinger, Nathan [mailto:nneul@umr.edu]
Sent: Friday, November 09, 2001 10:53 AM
To: 'krbdev@mit.edu'
Subject: memory leaks in krb524d.... (patch to fix)
Krb524 leaks memory on each request... In lookup_service_key, the keyblock
is partially copied, and copied incorrected, but the kt entry is never
freed.
That code never free's the entry that gets retrieved, which is a problem,
cause when it does that memcpy, it's copying the pointer to contents, not
the actual contents.
Index: krb524d.c
===================================================================
RCS file:
/afs/.umr.edu/software/krb5src/cvsroot/krb5-current/src/krb524/krb524d.c,v
retrieving revision 1.2
diff -u -r1.2 krb524d.c
--- krb524d.c 26 Jun 2001 13:58:23 -0000 1.2
+++ krb524d.c 9 Nov 2001 16:48:49 -0000
@@ -425,6 +425,13 @@
if ((ret = krb5_kt_get_entry(context, kt, p, kvno, ktype,
&entry)))
return ret;
memcpy(key, (char *) &entry.key, sizeof(krb5_keyblock));
+
+ key->contents = (krb5_octet *)malloc(key->length);
+ if ( key->contents )
+ memcpy((char *)key->contents, (char *)entry.key.contents,
+ key->length);
+
+ krb5_kt_free_entry(context, &entry);
return 0;
} else if (use_master) {
return kdc_get_server_key(context, p, key, kvnop, ktype, kvno);
It would be more appropriate to use krb5_copy_keyblock, however, that would
require a lot of other changes throughout krb524d.c. Would y'all be willing
to add a krb5_copy_keyblock equivalent that DID NOT do the allocation? In
that case, it would be a simple change to krb524d.c to make it use the
function instead.
The reason this is a problem is that it leaks 104 bytes per request (at
least with the requests I'm doing locally). That adds up pretty quick if
you're a heavy user of krb524d.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216