[19772] in Kerberos_V5_Development
Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash
daemon@ATHENA.MIT.EDU (Vipul Mehta)
Fri Jun 15 14:11:26 2018
MIME-Version: 1.0
In-Reply-To: <0e954174-4a9e-a117-499c-ff4f88b28176@mit.edu>
From: Vipul Mehta <vipulmehta.1989@gmail.com>
Date: Fri, 15 Jun 2018 23:27:54 +0530
Message-ID: <CAMeQEL-X_0JN2CJ3V=dhY6T001DXV6eaYfocnzgAmfVoub7X3Q@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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 <ghudson@mit.edu> 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 krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
