segfault in spnego_mech.c

Marcus Granado smurca at
Fri Mar 6 14:28:45 EST 2009


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
latest revision of this file in trunk, I believe:

A quick description of the problem:

The function acc_ctx_new()@919 can fail with 3 possibilities in the

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

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

A quick way to test the bug: if the input_token sent to
gss_accept_sec_context() is not null, but an empty buffer (i.e.
GSS_C_EMPTY_BUFFER instead of GSS_C_NO_BUFFER), line 1257 will call
acc_ctx_new() with an empty input_token (len=0) in its buf parameter, and
send that to get_negTokenInit()@2032 -> g_verify_token_header()@2802, which
will fail with a G_BAD_TOK_HEADER because the size of the input_token is 0,
causing acc_ctx_new() to return an ERROR_TOKEN_SEND in return_token.

That will cause acc_ctx_new() to fail with a GSS_S_FAILURE and
return_token=ERROR_TOKEN_SEND. We'll be sent to cleanup at 1291, and the
condition (return_token != NO_TOKEN_SEND && return_token != CHECK_MIC) will
be true, calling make_spnego_toeknTarg_msg() with a NULL sc pointer, leading
to a crash.

Anyone else able to reproduce that as well?

I believe a solution is to improve the condition above at line 1292,
including also the possible return_token values INIT_TOKEN_SEND and
NO_TOKEN_SEND that can be returned by acc_ctx_new() [btw, I didn't check
what acc_ctx_cont() and acc_ctx_call_acc() could return in return_token],
but since the algorithm is not trivial, it will take someone knowledgeable
in the gssapi spec to assert that.


More information about the krbdev mailing list