MIT Kerberos 1.14 : gssint_get_mechanism_cred crash

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MIT Kerberos 1.14 : gssint_get_mechanism_cred crash

Vipul Mehta
Hi,

We are facing crash in our application while kerberos security context
initialization inside gssint_get_mechanism_cred function.

Stacktrace is as following:
0x00007f96b93e0641 in gssint_get_mechanism_cred (union_cred=0x7f96ac3fa5c0,
mech_type=0xe5d420) at g_glue.c:704
#5  0x00007f96b93e1caf in gss_init_sec_context
(minor_status=0x7f9685feda5c, claimant_cred_handle=0x7f96ac3fa5c0,
context_handle=0x7f969c458c98, target_name=0x7f969c1f8fa0,
    req_mech_type=<value optimized out>, req_flags=6, time_req=0,
input_chan_bindings=0x0, input_token=0x7f9685feda30, actual_mech_type=0x0,
output_token=0x7f9685feda20, ret_flags=0x0, time_rec=0x0)
    at g_init_sec_context.c:204
#6  0x00007f96bb666a55 in Curl_gss_init_sec_context () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#7  0x00007f96bb655f19 in Curl_input_negotiate () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#8  0x00007f96bb6306d4 in Curl_http_input_auth () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#9  0x00007f96bb631abd in Curl_http_readwrite_headers () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#10 0x00007f96bb649a4a in Curl_readwrite () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#11 0x00007f96bb65271a in multi_runsingle () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#12 0x00007f96bb6533ab in curl_multi_perform () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4
#13 0x00007f96bb64b154 in curl_easy_perform () from
/data2/HOME_10.2/server/bin/libpmcurl.so.4

Looks like memcmp is causing the issue.

&union_cred->mechs_array[i]->length is 9
mech_type->length is 9
mech_type->elements is not NULL
(&union_cred->mechs_array[i])->elements is also not NULL

Is anyone aware of such issue. Any possible fix ? Let me know if you need
more information.

--
Regards,
Vipul
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash

Greg Hudson
On 06/14/2018 07:05 AM, Vipul Mehta wrote:
> We are facing crash in our application while kerberos security context
> initialization inside gssint_get_mechanism_cred function.
[...]
> Looks like memcmp is causing the issue.
>
> &union_cred->mechs_array[i]->length is 9
> mech_type->length is 9
> mech_type->elements is not NULL
> (&union_cred->mechs_array[i])->elements is also not NULL
>
> Is anyone aware of such issue. Any possible fix ? Let me know if you
> need more information.

I am not aware of any such issue.  You should double-check that the cred
handle you are passing is a valid cred handle and was not previously
freed (although the usual method of releasing a cred handle should also
set the pointer to NULL, unless you made a copy of the cred handle
before releasing it).  If there is a memory corruption issue in the
application, you might be able to use valgrind to find it.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash

Vipul Mehta
Thanks Greg. If i have anything more related to mit kerberos i will share.
For now we are also suspecting and investigating possible internal bug in
our code only.

On Thu, Jun 14, 2018 at 8:33 PM, Greg Hudson <[hidden email]> wrote:

> On 06/14/2018 07:05 AM, Vipul Mehta wrote:
>
>> We are facing crash in our application while kerberos security context
>> initialization inside gssint_get_mechanism_cred function.
>>
> [...]
>
>> Looks like memcmp is causing the issue.
>>
>> &union_cred->mechs_array[i]->length is 9
>> mech_type->length is 9
>> mech_type->elements is not NULL
>> (&union_cred->mechs_array[i])->elements is also not NULL
>>
>> Is anyone aware of such issue. Any possible fix ? Let me know if you need
>> more information.
>>
>
> I am not aware of any such issue.  You should double-check that the cred
> handle you are passing is a valid cred handle and was not previously freed
> (although the usual method of releasing a cred handle should also set the
> pointer to NULL, unless you made a copy of the cred handle before releasing
> it).  If there is a memory corruption issue in the application, you might
> be able to use valgrind to find it.
>



--
Regards,
Vipul
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev