- Wine-gitlab - list.winehq.org

[PATCH v7 0/3] MR10232: ntdll: Avoid exposing non-user rsp in normal syscall return path
by Hoshino Lina (＠hoshinolina) 02 Mar '26

02 Mar '26

When rsp is outside the kernel stack, the SIGUSR1 handler considers the context "out of syscall" and reports the real register values to wineserver. rsp pointing into the syscall frame is used for iret returns. Commit 0a5f7a710365 moved this earlier in the return path, creating a window in the regular direct return path where rsp points neither to the kernel stack, nor to the expected user stack. When a thread is interrupted by SIGUSR1 within this window, this exposes a bogus stack pointer to GetThreadContext(), breaking the garbage collector in Unity applications. Fix the regression by first switching to the real user stack (needed so we don't break things by touching other registers), then, only if an iret path is coming up, switching to the syscall frame pointer. This fixes the regression introduced by 0a5f7a710365, since GetThreadContext() will now observe the proper stack pointer during regular syscall returns. Further work would be needed to solve other corner cases and ensure that the register context returned by GetThreadContext() behaves exactly as on Windows (with no kernel-mode context info ever returned), but that is a larger/more invasive change. Fixes: 0a5f7a710365 ("ntdll: Switch to the user stack before restoring the %fs register.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59333 Signed-off-by: Hoshino Lina lina(a)lina.yt -- v7: gitlab: Run ntdll tests with win64 architecture. ntdll/tests: Add a test for bogus SP values from GetThreadContext(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10232

2 4

[PATCH v6 0/3] MR10232: ntdll: Avoid exposing non-user rsp in normal syscall return path
by Hoshino Lina (＠hoshinolina) 02 Mar '26

02 Mar '26

When rsp is outside the kernel stack, the SIGUSR1 handler considers the context "out of syscall" and reports the real register values to wineserver. rsp pointing into the syscall frame is used for iret returns. Commit 0a5f7a710365 moved this earlier in the return path, creating a window in the regular direct return path where rsp points neither to the kernel stack, nor to the expected user stack. When a thread is interrupted by SIGUSR1 within this window, this exposes a bogus stack pointer to GetThreadContext(), breaking the garbage collector in Unity applications. Fix the regression by first switching to the real user stack (needed so we don't break things by touching other registers), then, only if an iret path is coming up, switching to the syscall frame pointer. This fixes the regression introduced by 0a5f7a710365, since GetThreadContext() will now observe the proper stack pointer during regular syscall returns. Further work would be needed to solve other corner cases and ensure that the register context returned by GetThreadContext() behaves exactly as on Windows (with no kernel-mode context info ever returned), but that is a larger/more invasive change. Fixes: 0a5f7a710365 ("ntdll: Switch to the user stack before restoring the %fs register.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59333 Signed-off-by: Hoshino Lina lina(a)lina.yt -- v6: gitlab: Run ntdll tests with win64 architecture. ntdll/tests: Add a test for bogus SP values from GetThreadContext(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10232

2 3

[PATCH v5 0/3] MR10232: ntdll: Avoid exposing non-user rsp in normal syscall return path
by Hoshino Lina (＠hoshinolina) 02 Mar '26

02 Mar '26

When rsp is outside the kernel stack, the SIGUSR1 handler considers the context "out of syscall" and reports the real register values to wineserver. rsp pointing into the syscall frame is used for iret returns. Commit 0a5f7a710365 moved this earlier in the return path, creating a window in the regular direct return path where rsp points neither to the kernel stack, nor to the expected user stack. When a thread is interrupted by SIGUSR1 within this window, this exposes a bogus stack pointer to GetThreadContext(), breaking the garbage collector in Unity applications. Fix the regression by first switching to the real user stack (needed so we don't break things by touching other registers), then, only if an iret path is coming up, switching to the syscall frame pointer. This fixes the regression introduced by 0a5f7a710365, since GetThreadContext() will now observe the proper stack pointer during regular syscall returns. Further work would be needed to solve other corner cases and ensure that the register context returned by GetThreadContext() behaves exactly as on Windows (with no kernel-mode context info ever returned), but that is a larger/more invasive change. Fixes: 0a5f7a710365 ("ntdll: Switch to the user stack before restoring the %fs register.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59333 Signed-off-by: Hoshino Lina lina(a)lina.yt -- v5: gitlab: Run ntdll tests with win64 architecture. ntdll/tests: Add a test for bogus SP values from GetThreadContext(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10232

2 3

[PATCH v3 0/3] MR10232: ntdll: Avoid exposing non-user rsp in normal syscall return path
by Hoshino Lina (＠hoshinolina) 02 Mar '26

02 Mar '26

When rsp is outside the kernel stack, the SIGUSR1 handler considers the context "out of syscall" and reports the real register values to wineserver. rsp pointing into the syscall frame is used for iret returns. Commit 0a5f7a710365 moved this earlier in the return path, creating a window in the regular direct return path where rsp points neither to the kernel stack, nor to the expected user stack. When a thread is interrupted by SIGUSR1 within this window, this exposes a bogus stack pointer to GetThreadContext(), breaking the garbage collector in Unity applications. Fix the regression by first switching to the real user stack (needed so we don't break things by touching other registers), then, only if an iret path is coming up, switching to the syscall frame pointer. This fixes the regression introduced by 0a5f7a710365, since GetThreadContext() will now observe the proper stack pointer during regular syscall returns. Further work would be needed to solve other corner cases and ensure that the register context returned by GetThreadContext() behaves exactly as on Windows (with no kernel-mode context info ever returned), but that is a larger/more invasive change. Fixes: 0a5f7a710365 ("ntdll: Switch to the user stack before restoring the %fs register.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59333 Signed-off-by: Hoshino Lina lina(a)lina.yt -- v3: gitlab: Run ntdll tests with win64 architecture. ntdll/tests: Add a test for bogus SP values from GetThreadContext(). ntdll: Avoid exposing non-user rsp in normal syscall return path https://gitlab.winehq.org/wine/wine/-/merge_requests/10232

2 3

[PATCH v2 0/1] MR10232: ntdll: Avoid exposing non-user rsp in normal syscall return path
by Hoshino Lina (＠hoshinolina) 02 Mar '26

02 Mar '26

When rsp is outside the kernel stack, the SIGUSR1 handler considers the context "out of syscall" and reports the real register values to wineserver. rsp pointing into the syscall frame is used for iret returns. Commit 0a5f7a710365 moved this earlier in the return path, creating a window in the regular direct return path where rsp points neither to the kernel stack, nor to the expected user stack. When a thread is interrupted by SIGUSR1 within this window, this exposes a bogus stack pointer to GetThreadContext(), breaking the garbage collector in Unity applications. Fix the regression by first switching to the real user stack (needed so we don't break things by touching other registers), then, only if an iret path is coming up, switching to the syscall frame pointer. This fixes the regression introduced by 0a5f7a710365, since GetThreadContext() will now observe the proper stack pointer during regular syscall returns. Further work would be needed to solve other corner cases and ensure that the register context returned by GetThreadContext() behaves exactly as on Windows (with no kernel-mode context info ever returned), but that is a larger/more invasive change. Fixes: 0a5f7a710365 ("ntdll: Switch to the user stack before restoring the %fs register.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59333 Signed-off-by: Hoshino Lina lina(a)lina.yt -- v2: ntdll: Avoid exposing non-user rsp in normal syscall return path https://gitlab.winehq.org/wine/wine/-/merge_requests/10232

2 1

[PATCH 0/3] MR10231: winegstreamer: Implement presentation clock functions for media sink.
by Ziqing Hui (＠zhui) 02 Mar '26

02 Mar '26

This is needed by MF sink writer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10231

2 3

[PATCH v7 0/1] MR10193: dlls/comdlg32：Add the implementation of IServiceProvider_fnQueryService to obtain IFolderView2
by pan hui (＠panhui) 02 Mar '26

02 Mar '26

An application adds a new button using IFileDialogCustomize_AddPushButton. The application obtains IServiceProvider_iface through QueryInterface using the parameter IFileDialogCustomize_iface of the callback function IFileDialogControlEvents_OnButtonClicked, and then uses IServiceProvider_iface to pass IID_IFolderView and IID_IFolderView2 through IServiceProvider_fnQueryService to obtain IFolderView2. After that, it obtains the selected files and folders through IFolderView2_GetSelection. Currently, the implementation of obtaining IFolderView2 through IServiceProvider_fnQueryService is missing and needs to be added. -- v7: dlls/comdlg32：Add the implementation of IServiceProvider_fnQueryService to obtain IFolderView2 https://gitlab.winehq.org/wine/wine/-/merge_requests/10193

2 1

[PATCH v3 0/2] MR10008: start: Fix arg parsing for quoted paths ending with backslash.
by Yeshun Ye (＠yeyeshun) 02 Mar '26

02 Mar '26

When using the `start` command with a `/d` switch specifying a quoted path that ends with a backslash (e.g., `start /d "c:\path\" app.exe`), subsequent arguments were incorrectly concatenated into the path string due to parsing ambiguity. The error I encountered was with `start /d "c:\temp\" test.exe`, which was parsed into the arguments `/d` and `"c:\temp\" test.exe`. The path and the executable were merged into a single argument as a new path, preventing the child process from launching. In my first patch, I attempted to identify and split this combined argument, but this caused test failures in `kernel32`. I then retested on Windows and found that Windows also parses it as `/d` and `"c:\temp\" test.exe`—Wine's parsing is consistent with Windows. However, `start` works correctly on Windows because it is a built-in command, whereas in Wine, `start` is an external executable, leading to different behavior. Signed-off-by: YeshunYe yeyeshun(a)uniontech.com -- v3: start: Re-parsing the command line. https://gitlab.winehq.org/wine/wine/-/merge_requests/10008

3 5

[PATCH v2 0/1] MR10230: combase: Add RoFailFastWithErrorContext stub
by Alistair Leslie-Hughes (＠alesliehughes) 02 Mar '26

02 Mar '26

-- v2: combase: Add RoFailFastWithErrorContext stub https://gitlab.winehq.org/wine/wine/-/merge_requests/10230

3 2

[PATCH 0/1] MR10230: combase: Add RoFailFastWithErrorContext stub
by Alistair Leslie-Hughes (＠alesliehughes) 02 Mar '26

02 Mar '26

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10230

3 3