vauth: clear SSPI credentials on AcquireCredentialsHandle failure

[pen-pal]

Summary

Three small SSPI cleanup patches across lib/vauth/:

• krb5_sspi.c — clear krb5->credentials after a failed AcquireCredentialsHandle()
• spnego_sspi.c — clear nego->credentials after a failed AcquireCredentialsHandle()
• ntlm_sspi.c — clear ntlm->credentials after a failed AcquireCredentialsHandle()

The problem

Per the Microsoft SSPI contract for AcquireCredentialsHandle, on failure the output handle is invalid and must not be passed to any other security function.
The current code in all three sites leaves the heap-allocated CredHandle buffer referenced from the auth struct, which produces two real-world consequences:

1. API misuse on cleanup. Each protocol's cleanup function (Curl_auth_cleanup_gssapi, Curl_auth_cleanup_spnego, Curl_auth_cleanup_ntlm) later calls FreeCredentialsHandle() on the calloc'd-but-invalid handle. In practice all Windows SSPI
   providers I'm aware of return SEC_E_INVALID_HANDLE and do not crash, but this is API misuse and not contract-safe across SSPI provider implementations.

2. State-machine wart (krb5, spnego only). The outer if(!field->credentials) guard at the top of each function skips re-initialization on subsequent calls. After a transient AcquireCredentialsHandle failure, the field stays non-NULL but invalid, so the next attempt at authentication on the same connection re-enters with a dead handle and InitializeSecurityContext fails — the connection's auth is wedged until the connection itself is torn down. NTLM is not affected by this aspect since it calls Curl_auth_cleanup_ntlm at function entry.

The fix

On the AcquireCredentialsHandle failure path, curlx_free the buffer and set the field to NULL. After the change:

• The cleanup function's if(field->credentials) guard correctly skips the invalid handle.
• For krb5 and spnego, the outer guard allows the next call to re-attempt initialization.
• No behavior change in the success path.

Testing

• Build: cross-compiled clean for x86_64-w64-mingw32 (gcc 15.2.0) with --enable-sspi. Zero warnings or errors across the full libcurl build. The three patched objects emit as PE/COFF.
• Style: make checksrc passes.
• Runtime: I do not have a Windows development environment, so I have not exercised the patched paths against live Kerberos/Negotiate/NTLM providers. Reviewers with Windows CI access would help confirm by hitting a deliberately broken auth scenario (bad principal, unreachable KDC, etc.) and verifying retry behavior.

[jay]

the comments aren't needed and you can use curlx_safefree to null it for example

    if(status != SEC_E_OK) {
      curlx_safefree(krb5->credentials);
      return CURLE_LOGIN_DENIED;
    }

That said I'm not sure this is needed. FreeCredentialsHandle does not crash on invalid handle and for the 2nd problem I don't think we can end up after a login denied where the credentials is used but better safe than sorry I guess so I'm not opposed.

[bagder]

I'm just a bit concerned that this is done blindly (with an AI) without even testing it manually once.

[jay]

I'm just a bit concerned that this is done blindly (with an AI) without even testing it manually once.

Considering what it does I think it's fine. He's clearing the credentials for something that may happen and I don't see a need to find a code path where it does happen because it's good practice to do that. Generally, FreeCredentialsHandle on zeroed credentials or credentials from a failed AcquireCredentialsHandle is ok, we do it elsewhere, however in the case of SSPI he's right that we're evaluating credentials as a condition of initialization. So, hallucination or not it seems like a good idea for SSPI.

[jay]

Thanks