RFC 2744 permits a GSS-API implementation to delete an existing security context on a second or subsequent call to gss_init_sec_context() or gss_accept_sec_context() if the call results in an error. This API behavior has been found to be dangerous, leading to the possibility of memory errors in some callers. For safety, GSS-API implementations should instead preserve existing security contexts on error until the caller deletes them. References: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8598 Upstream patch: https://github.com/krb5/krb5/commit/56f7b1bc95a2a3eeb420e069e7655fb181ade5cf
Created krb5 tracking bugs for this issue: Affects: fedora-all [bug 1488874]
Analysis: The problem exists in gss_init_sec_context() and gss_accept_sec_context(). These functions delete an existing security context structure, when internal union_ctx_id->internal_ctx_id is set to GSS_C_NO_CONTEXT. This security context structure is a part of a bigger union context, which is later freed. So essentially this results in a double-free. This should not be really exploitable apart from crash. The crash should only occur in rare circumstances when the affected code is hit.