Subject: | k5_expand_path_tokens_extra() always returns 0 even if expand_token() fails |
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.
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.