https://bugs.winehq.org/show_bug.cgi?id=51049
Bug ID: 51049 Summary: Sea of Thieves crash when entering a lobby Product: Wine Version: 6.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs@winehq.org Reporter: leslie_alistair@hotmail.com Distribution: ---
After you set Sail in "Sea of Thieves", it crash due to a secur32 error.
Prior to to commit f93284dfa44b060436c6a0617b51280abb3f24fc, it worked as expected.
The crash occurs in function schan_InitializeSecurityContextW. The scenario is that it create a SCHAN_HANDLE_CTX handle, then later frees it. Then attempts to create another SCHAN_HANDLE_CTX, however passes the same parameters through except pInput (which is NULL).
Previous, this would return SEC_E_INCOMPLETE_MESSAGE, since the pInput was NULL, however however now, it jumps through to else if (!is_dtls_context(ctx)) return SEC_E_INCOMPLETE_MESSAGE;
However the ctx has already been freed in this case and then crashes.
https://bugs.winehq.org/show_bug.cgi?id=51049
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net Keywords| |regression Regression SHA1| |f93284dfa44b060436c6a0617b5 | |1280abb3f24fc
https://bugs.winehq.org/show_bug.cgi?id=51049
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/secur32-Initiali | |zeSecurityContextW Status|NEW |STAGED CC| |GloriousEggroll@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51049
--- Comment #1 from Hans Leidekker hans@meelstraat.net --- (In reply to Alistair Leslie-Hughes from comment #0)
After you set Sail in "Sea of Thieves", it crash due to a secur32 error.
Prior to to commit f93284dfa44b060436c6a0617b51280abb3f24fc, it worked as expected.
Before DTLS support it may have used a fallback path, presumably regular TLS.
The crash occurs in function schan_InitializeSecurityContextW. The scenario is that it create a SCHAN_HANDLE_CTX handle, then later frees it. Then attempts to create another SCHAN_HANDLE_CTX, however passes the same parameters through except pInput (which is NULL).
Previous, this would return SEC_E_INCOMPLETE_MESSAGE, since the pInput was NULL, however however now, it jumps through to else if (!is_dtls_context(ctx)) return SEC_E_INCOMPLETE_MESSAGE;
However the ctx has already been freed in this case and then crashes.
We should probably reject invalid handles to avoid a crash, but it seems to me the real problem might be in a previous call.
https://bugs.winehq.org/show_bug.cgi?id=51049
--- Comment #2 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Created attachment 69916 --> https://bugs.winehq.org/attachment.cgi?id=69916 +secur32 log without staging fix
AS you can see in the log 0x00007f8f765227b0 schan_InitializeSecurityContextW+0x560 [Z:\home\alesliehughes\source\wine-alesliehughes\dlls\secur32\schannel.c:926] in secur32: cmpq $d,0x0000000000000070(%rax) 926 else if (!is_dtls_context(ctx)) return SEC_E_INCOMPLETE_MESSAGE;
This is the point of failure since in this case ctx is NULL. (The handle has been freed).
Limiting the log to thread 05e4, shows that the InitializeSecurityContextW is called multiple times with the same handle, including after a DeleteSecurityContext.
Any thoughts would be grateful.
https://bugs.winehq.org/show_bug.cgi?id=51049
--- Comment #3 from Hans Leidekker hans@meelstraat.net --- (In reply to Alistair Leslie-Hughes from comment #2)
Created attachment 69916 [details] +secur32 log without staging fix
AS you can see in the log 0x00007f8f765227b0 schan_InitializeSecurityContextW+0x560 [Z:\home\alesliehughes\source\wine-alesliehughes\dlls\secur32\schannel.c: 926] in secur32: cmpq $d,0x0000000000000070(%rax) 926 else if (!is_dtls_context(ctx)) return SEC_E_INCOMPLETE_MESSAGE;
This is the point of failure since in this case ctx is NULL. (The handle has been freed).
Limiting the log to thread 05e4, shows that the InitializeSecurityContextW is called multiple times with the same handle, including after a DeleteSecurityContext.
It deletes the context after the second call to InitializeSecurityContext, which correctly fails because a NULL input buffer is passed. It then calls InitializeSecurityContext a third time with the freed context, which might be the result of poor error handling.
So the question is why a NULL input buffer is passed in the second call. It should hold the response from the server to the token produced with the first call.
https://bugs.winehq.org/show_bug.cgi?id=51049
--- Comment #4 from Hans Leidekker hans@meelstraat.net --- Do you still see this after ddf8c92721d230a880ae2171224e1785e6f29817?
https://bugs.winehq.org/show_bug.cgi?id=51049
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |c1993458ac3b4be9af4f8c47f5d | |e2cbd739f902b
--- Comment #5 from Hans Leidekker hans@meelstraat.net --- The crash should be fixed with c1993458ac3b4be9af4f8c47f5de2cbd739f902b.
https://bugs.winehq.org/show_bug.cgi?id=51049
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.0-rc1.