May 2025 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR8141: gdiplus: Add check of type parameter to be positive (ASan).
by Bernhard Übelacker May 26, 2025

May 26, 2025

Function GdipGetImageAttributesAdjustedPalette gets [called with type = -1](https://gitlab.winehq.org/wine/wine/-/blob/22af42ac22279e6c0c671f033661f95c1761b4bb/dlls/gdiplus/tests/image.c?page=6#L5649) and therefore accesses several arrays at index -1. This patch adds a helper which additionally checks for `type >= ColorAdjustTypeDefault`. <details> <summary>ASan output</summary> ``` ================================================================= ==gdiplus_test.exe==308==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f21342c57f8 at pc 0x6ffffadfd25b bp 0x7ffffe1ff750 sp 0x7ffffe1ff798 READ of size 4 at 0x7f21342c57f8 thread T0 #0 0x6ffffadfd25a in apply_image_attributes .../dlls/gdiplus/graphics.c:929:41 #1 0x6ffffae5c2f2 in GdipGetImageAttributesAdjustedPalette .../dlls/gdiplus/imageattributes.c:123:5 #2 0x000140084b59 in test_getadjustedpalette .../dlls/gdiplus/tests/image.c:5649:12 #3 0x000140062be6 in func_image .../dlls/gdiplus/tests/image.c:6719:5 #4 0x0001400c9132 in run_test .../include/wine/test.h:765:5 #5 0x0001400c8b50 in main .../include/wine/test.h:884:12 #6 0x0001400cad3a in mainCRTStartup .../dlls/msvcrt/crt_main.c:60:11 #7 0x6fffffc45aa0 in BaseThreadInitThunk .../dlls/kernel32/thread.c:61:24 #8 0x6fffffdcc776 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004c776) 0x7f21342c57f8 is located 144 bytes after 1256-byte region [0x7f21342c5280,0x7f21342c5768) freed by thread T0 here: #0 0x6ffffe88aab1 in free C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan\asan_malloc_win.cpp:71:3 #1 0x6ffffae5c21d in GdipDisposeImageAttributes .../dlls/gdiplus/imageattributes.c:109:5 #2 0x000140083598 in test_colorkey .../dlls/gdiplus/tests/image.c:3709:5 #3 0x000140062bd7 in func_image .../dlls/gdiplus/tests/image.c:6716:5 #4 0x0001400c9132 in run_test .../include/wine/test.h:765:5 #5 0x0001400c8b50 in main .../include/wine/test.h:884:12 #6 0x0001400cad3a in mainCRTStartup .../dlls/msvcrt/crt_main.c:60:11 #7 0x6fffffc45aa0 in BaseThreadInitThunk .../dlls/kernel32/thread.c:61:24 #8 0x6fffffdcc776 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004c776) previously allocated by thread T0 here: #0 0x6ffffe88ace6 in calloc C:/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan\asan_malloc_win.cpp:91:3 #1 0x6ffffae5c0fc in GdipCreateImageAttributes .../dlls/gdiplus/imageattributes.c:87:18 #2 0x000140082bf9 in test_colorkey .../dlls/gdiplus/tests/image.c:3629:12 #3 0x000140062bd7 in func_image .../dlls/gdiplus/tests/image.c:6716:5 #4 0x0001400c9132 in run_test .../include/wine/test.h:765:5 #5 0x0001400c8b50 in main .../include/wine/test.h:884:12 #6 0x0001400cad3a in mainCRTStartup .../dlls/msvcrt/crt_main.c:60:11 #7 0x6fffffc45aa0 in BaseThreadInitThunk .../dlls/kernel32/thread.c:61:24 #8 0x6fffffdcc776 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004c776) SUMMARY: AddressSanitizer: heap-buffer-overflow .../dlls/gdiplus/graphics.c:929:41 in apply_image_attributes Shadow bytes around the buggy address: 0x7f21342c5500: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x7f21342c5580: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x7f21342c5600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x7f21342c5680: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x7f21342c5700: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa =>0x7f21342c5780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x7f21342c5800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f21342c5880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f21342c5900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f21342c5980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f21342c5a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==gdiplus_test.exe==308==ABORTING ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8141

2 2

[PATCH 0/4] MR8143: amstream: Improve DDSURFACEDESC to AM_MEDIA_TYPE conversion, part 1/2.
by Elizabeth Figura (＠zfigura) May 26, 2025

May 26, 2025

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

2 4

[PATCH 0/3] MR8142: dmime: Cut down on the fixmes for unsupported MIDI meta events
by Michael Stefaniuc (＠mstefani) May 25, 2025

May 25, 2025

Noticed while testing https://bugs.winehq.org/show_bug.cgi?id=22018 . -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8142

2 4

Re: [PATCH v2 0/1] MR7747: ntdll: Guess optical disc type based on data size.
by Jinoh Kang (＠iamahuman) May 25, 2025

May 25, 2025

On Fri May 23 04:23:45 2025 +0000, Alex Henrie wrote: > Linux has only three [DVD > ioctls](https://docs.kernel.org/userspace-api/ioctl/cdrom.html): > DVD_READ_STRUCT, DVD_WRITE_STRUCT, and DVD_AUTH. It has no blu-ray > ioctls. Of the three DVD ioctls, only DVD_READ_STRUCT would be suitable > for disc type detection. > DVD_READ_STRUCT can read five kinds of information: DVD_STRUCT_PHYSICAL, > DVD_STRUCT_COPYRIGHT, DVD_STRUCT_DISCKEY, DVD_STRUCT_BCA, and > DVD_STRUCT_MANUFACT. Of those five, only DVD_STRUCT_PHYSICAL would be > suitable for disc type detection. > At least on my LG WH16NS40 drive, DVD_STRUCT_PHYSICAL succeeds when > there is a DVD in the drive, but it fails when there is a CD or a > blu-ray in the drive. That means that we could use DVD_STRUCT_PHYSICAL > to accurately detect whether there is a DVD in the drive, but we would > still need another way to detect blu-rays. > Is there another ioctl that you had in mind, or something else that I > missed? Do you want to try DVD_STRUCT_PHYSICAL first and fall back to > guessing based on the data size if it fails? Please let me know how to proceed. Any chance it could be a driver bug? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7747#note_104478

1 0

Re: [PATCH v50 0/2] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) May 25, 2025

May 25, 2025

and the rest looks good to me -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_104475

1 0

Re: [PATCH v50 0/2] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) May 25, 2025

May 25, 2025

eric pouech (@epo) commented about programs/cmd/wcmdmain.c: > + > + /* Calculate cursor position at beginning of prompt, accounting for lines scrolled > + * due to length of input. > + */ > + GetConsoleScreenBufferInfo(hOutput, &currentConsoleInfo); > + currentConsoleInfo.dwCursorPosition.X = startConsoleInfo.dwCursorPosition.X; > + len2 -= (currentConsoleInfo.dwSize.X - currentConsoleInfo.dwCursorPosition.X); > + if (len2 > 0) { > + currentConsoleInfo.dwCursorPosition.Y -= ((len2 / currentConsoleInfo.dwSize.X) + 1); > + } > + SetConsoleCursorPosition(hOutput, currentConsoleInfo.dwCursorPosition); > + > + WriteConsoleW(hOutput, inputBuffer, len, &numWritten, NULL); > + if (maxLen > len) { > + clear_console_characters(hOutput, maxLen - len, lastConsoleInfo.dwSize.X); /* width at time of last console update */ > + } and likely you could do 'maxLen = len;' here: as screen is "cleared" after 'len' position, there's no need to clear it again (unless a wider string is needed, but you'll catch that later) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_104474

1 0

Re: [PATCH v50 0/2] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) May 25, 2025

May 25, 2025

eric pouech (@epo) commented about programs/cmd/wcmdmain.c: > + len = lstrlenW(inputBuffer); > + len2 = len; > + > + /* Update current input display in console */ > + set_cursor_visible(hOutput, FALSE); > + > + /* Calculate cursor position at beginning of prompt, accounting for lines scrolled > + * due to length of input. > + */ > + GetConsoleScreenBufferInfo(hOutput, &currentConsoleInfo); > + currentConsoleInfo.dwCursorPosition.X = startConsoleInfo.dwCursorPosition.X; > + len2 -= (currentConsoleInfo.dwSize.X - currentConsoleInfo.dwCursorPosition.X); > + if (len2 > 0) { > + currentConsoleInfo.dwCursorPosition.Y -= ((len2 / currentConsoleInfo.dwSize.X) + 1); > + } > + SetConsoleCursorPosition(hOutput, currentConsoleInfo.dwCursorPosition); did you try just reusing startConsoleInfo.dwCursorPosition here instead of recomputing the initial cursor position? Actually I'm worried that we have to convert between cursor position from/to number of characters - this makes assumptions about how the string is layed out (one vs multiple lines, one string character == one cell == one glyph on screen (this is not the case for CJK characters; if we support them one day)) - anyway, I don't see a simple straightforward way to do it (ReadConsole doesn't return the farthest cursor point where it has written to, and since it can be on multiple lines...). - but the less code that does it, the better the pain here comes from conhost wrapping the strings (in WriteConsole) larger than screen buffer width onto different lines... native use an unbounded line length and wraps it depending on window size. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_104473

1 0

Re: [PATCH v50 0/2] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) May 25, 2025

May 25, 2025

eric pouech (@epo) commented about programs/cmd/wcmdmain.c: > + } > +} > + > +/* Intended as a mostly drop-in replacement for ReadConsole, but with tab-completion support. > + */ > +BOOL WCMD_read_console(const HANDLE hInput, WCHAR *inputBuffer, const DWORD inputBufferLength, LPDWORD numRead) > +{ > + HANDLE hOutput = GetStdHandle(STD_OUTPUT_HANDLE); > + SEARCH_CONTEXT sc = {0}; > + WCHAR *lastResult = NULL; > + CONSOLE_SCREEN_BUFFER_INFO startConsoleInfo, lastConsoleInfo, currentConsoleInfo; > + DWORD numWritten; > + UINT oldCurPos, curPos; > + BOOL done = FALSE; > + BOOL ret = FALSE; > + static int maxLen = 0; /* Track maximum length in case user fetches a long string from a previous iteration in history. */ I don't see why this variable needs to be static... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_104472

1 0

Re: [PATCH v17 0/1] MR6199: winewayland: Fix release_all_keys's modifier filtering.
by Yuri Hérouard May 25, 2025

May 25, 2025

On Sun May 25 15:34:38 2025 +0000, Alexandros Frantzis wrote: > Hi @yurih, from what I understand the reason alt(-tab) is problematic is > because the alt menu mode is enabled when the key is released. However, > avoiding the release just for this behavior doesn't seem like a viable > way forward, since other applications may treat alt differently or may > also require treating other keys the same way. > I was experimenting a bit and sending WM_CANCELMODE (which winex11 does > already) seems to help with the alt(-tab) menu situation in my tests. > Could you try the following and let me know if it helps with your use case: > ```patch > --- a/dlls/winewayland.drv/wayland_keyboard.c > +++ b/dlls/winewayland.drv/wayland_keyboard.c > @@ -800,6 +800,11 @@ static void keyboard_handle_leave(void *data, > struct wl_keyboard *wl_keyboard, > * and for any key repetition to stop. */ > release_all_keys(hwnd); > > + if (hwnd == NtUserGetForegroundWindow()) > + { > + if (!(NtUserGetWindowLongW(hwnd, GWL_STYLE) & WS_MINIMIZE)) > + send_message(hwnd, WM_CANCELMODE, 0, 0); > + } > /* FIXME: update foreground window as well */ > } > ``` Yes it does indeed fix the alt menu mode without my patch. Though I don't think I understood clearly what you meant, as Alt is already filtered (VK_MENU), I just added the left and right keys as they are among the returned keyboard state and are not filtered, making Alt released anyway. You plan to remove the modifier's filtering altogether ? Also, there's issues with extended scan code (for example my keyboard arrows) that aren't released, though it also happens with winex11. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6199#note_104470

1 0

[PATCH v4 0/1] MR8137: kernel32: Implement ReadConsoleInputEx
by Jayson Reis (＠jaysonsantos) May 25, 2025

May 25, 2025

This implements the method only with empty flags, nowait (0x2) and all flags on noremove(0x1) | nowait(0x2) -- v4: kernel32: Implement ReadConsoleInputEx https://gitlab.winehq.org/wine/wine/-/merge_requests/8137

2 1