Assertion failed at tkey.c:490 due to missing GSSAPI

Andrew Bartlett abartlet at
Thu Mar 8 02:26:13 UTC 2012

I'm working with fellow Samba developer Kelly (CC'ed), who has been

tkey.c:490: ENSURE(result == (((1) << 16) + 28) || result == 0) failed,
back trace

Looking at the Bind 9.8.1 sources, it seems this is the code

	 * Note that tctx->gsscred may be NULL if tctx->gssapi_keytab is set
	result = dst_gssapi_acceptctx(tctx->gsscred, tctx->gssapi_keytab,
				      &outtoken, &gss_ctx,
	if (result == DNS_R_INVALIDTKEY) {
		if (tsigkey != NULL)
		tkeyout->error = dns_tsigerror_badkey;
		tkey_log("process_gsstkey(): dns_tsigerror_badkey");    /* XXXSRA */
		return (ISC_R_SUCCESS);
	} else if (result == ISC_R_FAILURE)
		goto failure;
	ENSURE(result == DNS_R_CONTINUE || result == ISC_R_SUCCESS);

The ENSURE() statement does not consider that dst_gssapi_acceptctx()
could return (ISC_R_NOMEMORY) or (ISC_R_NOTIMPLEMENTED) if not compiled
with the 'ideal' headers.

We are working to fix up Kelly's workstation to have GSSAPI, but
otherwise this appears to be an unauthenticated DoS on the server, so we
figured you might be interested. 


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the bind-workers mailing list