Signed-off-by: Paul Gofman pgofman@codeweavers.com --- Certain failures in InitializeSecurityContextW may leave output context unitialized. Freeing that on error path below may cause access violation. It seems to me that just zeroing the context is easier and less fragile rather than accurately guessing which possible InitializeSecurityContextW() status requires freeing the handle or not.
On a separate note, I tested that Windows DeleteSecurityContext may also have an exception given invalid context but it catches that (probably like other secur32 functions in similar cases) and returns SEC_E_INVALID_HANDLE: https://gist.github.com/gofman/7960b67a0fadaae843157b5556a1c003. I am not immediately sure if we want to fix that now in secur32 (I am not aware of any specific app depending on that), in case we will we can factor out structure getter and either use __TRY / __CATCH or add a magic number to the structure. In any case I suppose avoiding hitting this case in winhttp worth it regardless.
dlls/winhttp/net.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/winhttp/net.c b/dlls/winhttp/net.c index 2fc48476513..07a65c5465f 100644 --- a/dlls/winhttp/net.c +++ b/dlls/winhttp/net.c @@ -293,6 +293,7 @@ DWORD netconn_secure_connect( struct netconn *conn, WCHAR *hostname, DWORD secur
if (!(read_buf = malloc( read_buf_size ))) return ERROR_OUTOFMEMORY;
+ memset( &ctx, 0, sizeof(ctx) ); status = InitializeSecurityContextW(cred_handle, NULL, hostname, isc_req_flags, 0, 0, NULL, 0, &ctx, &out_desc, &attrs, NULL);