kern/161884: Gssapi/krb5 memory leak, massive krb5.conf re-read slowness

Harry Coin hcoin at
Fri Oct 21 16:50:09 UTC 2011

>Number:         161884
>Category:       kern
>Synopsis:       Gssapi/krb5 memory leak, massive krb5.conf re-read slowness
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Oct 21 16:50:07 UTC 2011
>Originator:     Harry Coin
>Release:        8Stable
Quiet Fountain LLC
Notice in

and elsewhere where gssapi meets kerberos we see gssapi mechanism procedures which are entered frequently.  Such as every time a user connects to an NFS share, every time SASL/gssapi/kerberos via SASL to get an LDAP lookup happens.

These procedures have something like this:

. processing..
and then exit without freeing the kerberos context.  That context has in it many memory allocations for extensive internal structures, none of which are released when the subroutine is simply exited before freeing it.

Worse than that by many standards:  the business of creating a kerberos context involves reading and parsing the krb5.conf file.. which in turn makes references to potentially a gracious plenty other files.   This gssapi code involving kerberos should create the context one time when the process begins, then keep it open and re-use the context straight on until the process ends.   Frequently building and discarding the context every time credentials have to be checked between a principal and a local user name is incredibly wasteful of time and disk traffic.

Set up an nfs export using -sec=krb5xx.  Watch memory use go up in gssd for example.


_gsskrb5_pname_to_uid(OM_uint32 *minor_status, const gss_name_t pname,
    const gss_OID mech, uid_t *uidp)

	kret = krb5_aname_to_localname(context, name, sizeof(lname), lname);
 	//printf("Kret %d lname %s\n",kret,lname);
+	krb5_free_context(context);
	if (kret) {
		*minor_status = kret;
		return (GSS_S_FAILURE);

. this just fixes the memory leak, it doesn't fix the waste involved in building a whole context and throwing it away every time gssapi needs to check what principal goes with which user.   Note also the previous bug report increasing the password buffer size from 128 to 1024, since long prinicpal names, long passwords, long home directories and long gecos info often extends beyond 128 bytes so causing nfs shares to be denied access owing to wrongful authentication failures.


More information about the freebsd-bugs mailing list