[krbdev.mit.edu #8455] k5_expand_path_tokens_extra() always returns 0 even if expand_token() fails

Will Fiveash via RT rt-comment at krbdev.mit.edu
Fri Jul 15 16:58:44 EDT 2016


This is part of a description of a bug opened at Oracle against Solaris
krb which is based on MIT v1.14.3:

It seems that the root cause of the Segmentation Fault (addr=0) is in
function libkrb5.so.3.3`k5_expand_path_tokens_extra(). Because it throws
away
a non-zero return code and always returns 0 as shown below:

510        /* Expand this token and add its value. */
511        ret = expand_token(context, tok_begin, tok_end, extra_tokens,
512                           &tok_val);
513        if (ret)
514            goto cleanup;


537cleanup:
538    k5_buf_free(&buf);
539    free_extra_tokens(extra_tokens);
540    return 0;

This results in a NULL pointer 'name' to be passed to krb5_kt_resolve() at
line 57 below:

48krb5_error_code KRB5_CALLCONV
49krb5_kt_client_default(krb5_context context, krb5_keytab *keytab_out)
50{
51    krb5_error_code ret;
52    char *name;
53
54    ret = k5_kt_client_default_name(context, &name);
55    if (ret)
56        return ret;
57    ret = krb5_kt_resolve(context, name, keytab_out);
58    free(name);
59    return ret;
60}

krb5_kt_resolve()  calls strchr to find the ':' as the first thing and
cores.

As a workaround, setting the environment variable KRB5_CLIENT_KTNAME to the
name of the user, so the code below gets run, will fix the issue:

59krb5_error_code
60k5_kt_client_default_name(krb5_context context, char **name_out)
...
...
65    if (context->profile_secure == FALSE &&
66        (str = getenv("KRB5_CLIENT_KTNAME")) != NULL) {
67        *name_out = strdup(str);
=====================================================================
So to summarize, if expand_token() fails when called in
k5_expand_path_tokens_extra() it will return 0 with the path_out output
parameter set to NULL (the pointer variable passed in is assigned NULL).
 The earlier function in the call stack, krb5_kt_client_default() ends
up calling krb5_kt_resolve() which in turn calls:

    cp = strchr (name, ':');

with name == NULL which causes a core dump.


More information about the krb5-bugs mailing list