Ticket History #2384: KDC memory leak in TCP handling

I think Will's right about this KDC memory leak in TCP configurations.
Probably kill_tcp_connection should free the storage when a TCP
connection goes away. Need to look closer.

Return-Path: <william.fiveash@sun.com>
Received: from po9.mit.edu (po9.mit.edu [18.7.21.65])
by po9.mit.edu (Cyrus v2.1.5) with LMTP; Wed, 10 Mar 2004 20:02:22 -0500
X-Sieve: CMU Sieve 2.2
Received: from pacific-carrier-annex.mit.edu by po9.mit.edu (8.12.4/4.7) id i2B12LKc026252; Wed, 10 Mar 2004 20:02:21 -0500 (EST)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id i2B12K1U001912
for <raeburn@mit.edu>; Wed, 10 Mar 2004 20:02:20 -0500 (EST)
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14])
by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2B12Jex028676
for <raeburn@mit.edu>; Wed, 10 Mar 2004 18:02:19 -0700 (MST)
Received: from alton.central.sun.com (alton.Central.Sun.COM [129.153.128.101])
by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i2B12Jbq002535
for <raeburn@mit.edu>; Wed, 10 Mar 2004 18:02:19 -0700 (MST)
Received: from alton.central.sun.com (localhost [127.0.0.1])
by alton.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i2B12IpU881138
for <raeburn@mit.edu>; Wed, 10 Mar 2004 19:02:18 -0600 (CST)
Received: (from willf@localhost)
by alton.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i2B12IkC881137
for raeburn@mit.edu; Wed, 10 Mar 2004 19:02:18 -0600 (CST)
X-Authentication-Warning: alton.central.sun.com: willf set sender to william.fiveash@sun.com using -f
Date: Wed, 10 Mar 2004 19:02:18 -0600
From: Will Fiveash <william.fiveash@sun.com>
To: Ken Raeburn <raeburn@mit.edu>
Subject: Fwd: Fwd: possible memory leak in 1.3.2
X-Gnus-Mail-Source: pop:raeburn@nil
Message-ID: <20040311010218.GC159530@sun.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="lteA1dqeVaWQ9QQl"
Content-Disposition: inline
User-Agent: Mutt/1.4.2i
X-Spam-Score: -4.9
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Lines: 131
Xref: all-in-one personal:17575 all.2004-03:896


--lteA1dqeVaWQ9QQl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Ken,

I've sent this message a couple times to krbdev@MIT.EDU and last time
also to Jeffrey Altman. I don't know why I haven't heard anything so I
thought I'd see if you can get this e-mail.

----- Forwarded message from Will Fiveash <william.fiveash@sun.com> -----

Date: Tue, 9 Mar 2004 10:01:44 -0600
From: Will Fiveash <william.fiveash@sun.com>
Subject: Fwd: possible memory leak in 1.3.2
To: MIT Kerberos Dev List <krbdev@MIT.EDU>
Cc: Jeffrey Altman <jaltman@columbia.edu>
Mail-Followup-To: MIT Kerberos Dev List <krbdev@MIT.EDU>,
Jeffrey Altman <jaltman@columbia.edu>

I sent this yesterday but I never saw it on the krbdev list. BTW, I've
confirmed that there is a memory leak. I've attached a patch.

----- Forwarded message from Will Fiveash <william.fiveash@sun.com> -----

Date: Mon, 8 Mar 2004 18:33:26 -0600
From: Will Fiveash <william.fiveash@sun.com>
Subject: possible memory leak in 1.3.2
To: MIT Kerberos Dev List <krbdev@MIT.EDU>
Mail-Followup-To: MIT Kerberos Dev List <krbdev@MIT.EDU>

I'm testing the kdc with "kdc_ports =3D 0" in the kdc.conf which forces the=
kdc
to use TCP. What I notice is the virt. memory size of the kdc continues to
grow as I run 40 instances of kinit's over and over. I suspect a memory le=
ak
but I'm not sure at this point so I thought I'd see if someone on the list =
can
confirm my suspicion regarding certain fuctions. In src/kdc/network.c I se=
e:

add_fd (struct socksetup *data, int sock, int conntype,
void (*service)(struct connection *, const char *, int))
{
struct connection *newconn;
void *tmp;

newconn =3D malloc(sizeof(*newconn));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
if (newconn =3D=3D 0) {
data->retval =3D errno;
com_err(data->prog, errno,
"cannot allocate storage for connection info");
return 0;
}
if (!ADD(connections, newconn, tmp)) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
data->retval =3D errno;
com_err(data->prog, data->retval, "cannot save socket info");
free(newconn);
return 0;
}

and later there is:

static void
kill_tcp_connection(struct connection *conn)
{
delete_fd(conn);
^^^^^^^^^^^^^^^ does not free(conn)
if (conn->u.tcp.response)
krb5_free_data(kdc_context, conn->u.tcp.response);
if (conn->u.tcp.buffer)
free(conn->u.tcp.buffer);
FD_CLR(conn->fd, &sstate.rfds);
FD_CLR(conn->fd, &sstate.wfds);
if (sstate.max =3D=3D conn->fd + 1)
while (sstate.max > 0
&& ! FD_ISSET(sstate.max-1, &sstate.rfds)
&& ! FD_ISSET(sstate.max-1, &sstate.wfds)
/* && ! FD_ISSET(sstate.max-1, &sstate.xfds) */
)
sstate.max--;
close(conn->fd);
conn->fd =3D -1;
tcp_data_counter--;
}

So how is the newconn malloc'ed in add_fd() free()'ed?

--=20
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=3DCST6CDT)
GPG PubKey ID:0x7D31DC39, Key server: www.keyserver.net