This is one of the Venustech AD-LAB alleged vulnerabilities.

CVE-2007-5902
http://bugs.gentoo.org/show_bug.cgi?id=199214

This bug consists of an integer overflow in
svcauth_gss_get_principal() in src/lib/rpc/svc_auth_gss.c, which can
cause an invocation of memcpy() to overflow a zero-length allocated
buffer.  This is not a practical vulnerability due to the
nigh-impossibility of producing the conditions required to trigger the
bug.

   641  svcauth_gss_get_principal(SVCAUTH *auth)
   642  {
   643          struct svc_rpc_gss_data *gd;
   644          char *pname;
   645  
   646          gd = SVCAUTH_PRIVATE(auth);
   647  
   648          if (gd->cname.length == 0)
   649                  return (NULL);
   650  
   651          if ((pname = malloc(gd->cname.length + 1)) == NULL)
   652                  return (NULL);
   653  
   654          memcpy(pname, gd->cname.value, gd->cname.length);
   655          pname[gd->cname.length] = '\0';
   656  
   657          return (pname);
   658  }

If "gd->cname.length" is exactly SIZE_MAX, then the call to malloc()
will have an argument of zero due to the modular arithmetic used on
unsigned integer types in C.  If malloc(0) returns a non-null pointer
on a specific platform, then the subsequent memcpy() call can attempt
to copy SIZE_MAX bytes and overflow the zero-length buffer.

The value "gd->cname" results from calling krb5_unparse_name() with a
principal obtained during authentication.  To successfully exploit
this vulnerability, an attacker would need to successfully
authenticate using a principal name whose unparsed string
representation is exactly SIZE_MAX+1 bytes long.  Such a principal
name is very unlikely to exist, and even if such an unusual principal
did exist, the C implementation would have to successfully allocate a
buffer SIZE_MAX+1 bytes long, which almost certainly will not succeed.