segfault in spnego_mech.c

[Tom Yu]

Marcus Granado <smurca at googlemail.com> writes:

> Hi,
>
> I think there's a bug in spnego_mech.c leading to a segfault. The line
> numbers here are relative to the release 20899 at
> http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c?r=20899(the
> latest revision of this file in trunk, I believe:
> http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c
> ).
>
> A quick description of the problem:
>
> The function acc_ctx_new()@919 can fail with 3 possibilities in the
> return_token parameter: {INIT_TOKEN_SEND,NO_TOKEN_SEND,ERROR_TOKEN_SEND}.
>
> Now, the function spnego_gss_accept_sec_context()@1199 calls acc_ctx_new()
> at line 1248. If ret != GSS_S_COMPLETE, it goesto cleanup at 1291, checking for
> non-equality of only two possible values in return_token: NO_TOKEN_SEND and
> CHECK_MIC.
>
> If return_token is not any of them, it calls make_spnego_tokenTarg_msg(),
> dereferencing the NULL pointer sc and triggering a segfault! The pointer sc
> is not initialized at this point for two reasons: (1) we jumped over its
> initialization on line 1264 when we wentto cleanup at 1291; and (2) we might be
> calling gss_accept_sec_context for the first time with an null
> context_handle.

I believe this is related to, if not identical to, ticket #6402.