From nneul@umr.edu Sat Nov 10 16:07:56 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id QAA27336
for <bugs@RT-11.mit.edu>; Sat, 10 Nov 2001 16:07:56 -0500 (EST)
Received: from mx.rollanet.org (qmailr@mailsrv.rollanet.org [192.55.114.7])
by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA00255
for <krb5-bugs@mit.edu>; Sat, 10 Nov 2001 16:07:55 -0500 (EST)
Received: (qmail 3498 invoked from network); 10 Nov 2001 21:07:54 -0000
Received: from cessna.rollanet.org (HELO umr.edu) (nneul@216.229.93.21)
by mx.rollanet.org with SMTP; 10 Nov 2001 21:07:54 -0000
Message-Id: <3BED9729.1B881B26@umr.edu>
Date: Sat, 10 Nov 2001 15:07:53 -0600
From: Nathan Neulinger <nneul@umr.edu>
Sender: nneul@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: [Fwd: FW: memory leaks in krb524d.... (patch to fix)]
Responsible-Changed-From-To: gnats-admin->raeburn
Responsible-Changed-By: hartmans
Responsible-Changed-When: Fri Mar 1 14:28:51 2002
Responsible-Changed-Why:
It looks like this was applied to the branch. Any reason this is still open?
State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Sun Apr 7 19:11:27 2002
State-Changed-Why:
Comparing the branch to the trunk, Ken seems to have pulled this
patch onto the trunk, so this should be fixed
both in released and development code.
--------------0017CDE7B1DFF91253AD1CB3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
--------------0017CDE7B1DFF91253AD1CB3
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: by umr-mail03.cc.umr.edu
id <01C16958.724B4AA0@umr-mail03.cc.umr.edu>; Fri, 9 Nov 2001 13:55:13 -0600
Message-ID: <6CAC36C3427CEB45A4A6DF0FBDABA56D86D9CB@umr-mail03.cc.umr.edu>
From: "Neulinger, Nathan" <nneul@umr.edu>
To: "'openafs-devel@openafs.org'" <openafs-devel@openafs.org>
Subject: FW: memory leaks in krb524d.... (patch to fix)
Date: Fri, 9 Nov 2001 13:55:13 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
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
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id QAA27336
for <bugs@RT-11.mit.edu>; Sat, 10 Nov 2001 16:07:56 -0500 (EST)
Received: from mx.rollanet.org (qmailr@mailsrv.rollanet.org [192.55.114.7])
by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA00255
for <krb5-bugs@mit.edu>; Sat, 10 Nov 2001 16:07:55 -0500 (EST)
Received: (qmail 3498 invoked from network); 10 Nov 2001 21:07:54 -0000
Received: from cessna.rollanet.org (HELO umr.edu) (nneul@216.229.93.21)
by mx.rollanet.org with SMTP; 10 Nov 2001 21:07:54 -0000
Message-Id: <3BED9729.1B881B26@umr.edu>
Date: Sat, 10 Nov 2001 15:07:53 -0600
From: Nathan Neulinger <nneul@umr.edu>
Sender: nneul@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: [Fwd: FW: memory leaks in krb524d.... (patch to fix)]
Show quoted text
>Number: 1013
>Category: pending
>Synopsis: [Fwd: FW: memory leaks in krb524d.... (patch to fix)]
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: raeburn
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Nov 10 16:08:00 EST 2001
>Last-Modified: Sun Apr 7 19:12:10 EDT 2002
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Category: pending
>Synopsis: [Fwd: FW: memory leaks in krb524d.... (patch to fix)]
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: raeburn
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Nov 10 16:08:00 EST 2001
>Last-Modified: Sun Apr 7 19:12:10 EDT 2002
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->raeburn
Responsible-Changed-By: hartmans
Responsible-Changed-When: Fri Mar 1 14:28:51 2002
Responsible-Changed-Why:
It looks like this was applied to the branch. Any reason this is still open?
State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Sun Apr 7 19:11:27 2002
State-Changed-Why:
Comparing the branch to the trunk, Ken seems to have pulled this
patch onto the trunk, so this should be fixed
both in released and development code.
Show quoted text
>Unformatted:
This is a multi-part message in MIME format.--------------0017CDE7B1DFF91253AD1CB3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
--------------0017CDE7B1DFF91253AD1CB3
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: by umr-mail03.cc.umr.edu
id <01C16958.724B4AA0@umr-mail03.cc.umr.edu>; Fri, 9 Nov 2001 13:55:13 -0600
Message-ID: <6CAC36C3427CEB45A4A6DF0FBDABA56D86D9CB@umr-mail03.cc.umr.edu>
From: "Neulinger, Nathan" <nneul@umr.edu>
To: "'openafs-devel@openafs.org'" <openafs-devel@openafs.org>
Subject: FW: memory leaks in krb524d.... (patch to fix)
Date: Fri, 9 Nov 2001 13:55:13 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
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
Show quoted text
-----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
--------------0017CDE7B1DFF91253AD1CB3--
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
--------------0017CDE7B1DFF91253AD1CB3--