[PATCH v3 0/1] MR7479: wow64win: fix the access exception when the lparam is an address larger than 2G.
Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- v3: wow64win: change parameter types from LONG to ULONG in wow64_NtUserMessageCall https://gitlab.winehq.org/wine/wine/-/merge_requests/7479
From: Jiajin Cui <cuijiajin(a)uniontech.com> Changed wparam and lparam parameter types from LONG to ULONG in wow64_NtUserMessageCall function to match the expected data types from the get_ulong function. The get_ulong function returns unsigned 32- bit values, so using ULONG type ensures proper type compatibility and prevents potential sign extension issues when handling message parameters in 64-bit Windows emulation. When a 32-bit program sets the IMAGE_FILE_LARGE_ADDRESS_AWARE flag, lparam may be an address exceeding 2GB, such as 0x8defddef. If using ULONG to receive it, due to sign extension, the address becomes 0xffffffff8defddef, causing exceptions during subsequent address access. Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> --- dlls/wow64win/user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dlls/wow64win/user.c b/dlls/wow64win/user.c index d4f47773abe..398f0fa2f6f 100644 --- a/dlls/wow64win/user.c +++ b/dlls/wow64win/user.c @@ -3624,8 +3624,8 @@ NTSTATUS WINAPI wow64_NtUserMessageCall( UINT *args ) { HWND hwnd = get_handle( &args ); UINT msg = get_ulong( &args ); - LONG wparam = get_ulong( &args ); - LONG lparam = get_ulong( &args ); + ULONG wparam = get_ulong( &args ); + ULONG lparam = get_ulong( &args ); void *result_info = get_ptr( &args ); UINT type = get_ulong ( &args ); BOOL ansi = get_ulong( &args ); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/7479
@rbernon Could you spare some time to see if there are any issues with this modification? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7479#note_121760
It's difficult to say for sure, as it might depend on what wparam/lparam are meant for, and if lparams is supposed to be a signed integer, we need to sign extend it. Maybe a safe choice here would be to use the WPARAM/LPARAM types instead, which would avoid sign-extending wparam as WPARAM is unsigned, but still sign extend lparam. Which message are you seeing this with? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7479#note_121777
@rbernon While debugging the WeCom application, I found that when the application calls the SetWindowTextW interface, the LPARAM of the WM_SETTEXT message points to the text of the window title bar, and the address of this string is allocated by the application in memory space above 2GB. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7479#note_121799
The only place I could find lparam being used as a signed value is in SBM_SETRANGE. However it is also cast to int, so even if the parameter was not sign extended in the wow64 thunk, it gets sign extended there by the LPARAM -> int conversion. I think it's probably safe to do this, and the issues we need to be checking for regressions are cases where lparam is used as a signed 64bit value on the unix side, but it's probably unlikely. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7479#note_121999
This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7479
participants (3)
-
Jiajin Cui -
Jiajin Cui (＠jin-king1)
-
Rémi Bernon