May 2024 - Wine-bugs - list.winehq.org

[Bug 56591] New: Since commit a00efa12, Steam (Win) doesn't render individual game pages correctly.
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56591 Bug ID: 56591 Summary: Since commit a00efa12, Steam (Win) doesn't render individual game pages correctly. Product: Wine Version: 9.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com Regression SHA1: a00efa12e27035a4a1afb961daefa69766e86b17 Distribution: ArchLinux Created attachment 76346 --> https://bugs.winehq.org/attachment.cgi?id=76346 wine-steam-d3d.log (WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+d3d) Seems the issues are mainly with blocks of information that don't include pictures, just text - like game hotfix info, etc. I'm using the vulkan backend renderer for wined3d. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 52585] New: NtQueryDirectoryObject multiple entries not implemented, breaks shells on Cygwin
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=52585 Bug ID: 52585 Summary: NtQueryDirectoryObject multiple entries not implemented, breaks shells on Cygwin Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: megastallman(a)gmail.com Distribution: --- When I try running any command(not builtin) in Cygwin bash or sh, I get no output and no results in Wineconsole. Though, among usual harmless LDAP-related errors, Wineconsole outputs the following to terminal: 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented even after Enter is pressed. Builtin commands work fine, but no external command works at all. Reproducing steps: - cd /cygwin/path/bin - Run "wineconsole" from terminal. There you'll see NtQueryDirectoryObject error. - Run "uname" in Wineconsole. Despite FAST_CWD error, it works. - Run "sh" in Wineconsole. - Run "ls", or just press Enter, or run any other non-builtin command and see those 3 NtQueryDirectoryObject errors. Command itself will not just output anything, it won't work at all, just silently release the terminal. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 56665] New: ELF binaries are being built but its supposed to be PE build
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56665 Bug ID: 56665 Summary: ELF binaries are being built but its supposed to be PE build Product: Wine Version: 9.0 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Hello, as of wine 9, ELF binaries (dll.so) are being built but normally these should be PE binaries (.a). This is how we build wine: https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/emulators/wine I will try to find to the commit that is causing this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 56643] New: Ntdll support for custom baud rates
by WineHQ Bugzilla 13 Jun '24

13 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56643 Bug ID: 56643 Summary: Ntdll support for custom baud rates Product: Wine Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: testator(a)protonmail.ch Implementing custom baud rates across different OS's would be non-trivial but a useful prerequisite for some obscure apps like qemu or the "mode" command. Termios2 is a linux specific implementation of custom baud rates. In wine-9.8 there was a commit, 898ab8dab19d498c17859f39a55e317ee7e367a5 , that added termios2 usage via glibc headers which breaks compilation on musl based systems, doesn't work in osx, and doesn't work in *bsd. In https://opensource.apple.com/source/IOSerialFamily/IOSerialFamily-55/IOSeri… there is a way to set custom baud rates for osx via IOSSIOSPEED e.g <IOKit/serial/ioss.h> . Setting the rate on linux via <linux/termios.h> instead of the glibc specific extensions of <termios.h> would work as well with how its currently implemented in wine-9.8. It looks like net/openbsd use termios1 modified to their own thing to allow setting arbitrary speeds via tcsetattr https://github.com/openbsd/src/blob/master/lib/libc/termios/tcsetattr.c e.g <termios.h> . In general there doesn't seem to be a common unix implementation for setting custom baud rates and looks like a huge complicated mess to implement. The musl devs found this out already it seems openwall.com/lists/musl/2024/04/11/8 . -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 50591] New: ReadFile schedules async read when ReadIntervalTimeout is MAXDWORD
by WineHQ Bugzilla 13 Jun '24

13 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=50591 Bug ID: 50591 Summary: ReadFile schedules async read when ReadIntervalTimeout is MAXDWORD Product: Wine Version: 6.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: aaron.knister(a)gmail.com Distribution: --- Created attachment 69269 --> https://bugs.winehq.org/attachment.cgi?id=69269 ntdll: NtReadFile async reads always return success when avail_mode TRUE TeraTerm is ending up with missing data when it reads from a COM/Serial port. TeraTerm sets ReadIntervalTimeout to MAXDWORD and then calls ReadFile asynchronously, and if there's pending IO it waits 1 second for the overlapped struct event to be signalled. If the signal is received, it processes the received I/O, else continues on and will perform another ReadFile. This is the code snippet: if (!ReadFile(cv->ComID,&(cv->InBuff[cv->InBuffCount]), InBuffSize-cv->InBuffCount,&C,&rol)) { if (GetLastError() == ERROR_IO_PENDING) { if (WaitForSingleObject(rol.hEvent, 1000) != WAIT_OBJECT_0) { C = 0; } else { GetOverlappedResult(cv->ComID,&rol,&C,FALSE); } } What's happening in WINE, is ReadFile returns non-zero with ERROR_IO_PENDING and the WaitForSingleObject times out. The asynchronous read *does* complete after the timeout, but by that point the application has given up and moved on. I initially thought the application was at fault, because it should retry if the wait times out. However, in the documentation for ReadFile it points to documentation about COMMTIMEOUTS (https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-commt…) which says the following: A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received. To me, that means Wine ought not to be triggering an asynchronous read when the comm timeout parameters are set as indicated above. I coded a simple fix, which is in NtReadFile, if avail_mode is TRUE return success even if no bytes were read. See attached patch. It works for TeraTerm, I have no idea if it causes other regressions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 47778] New: world of warcraft in game store browser crashes
by WineHQ Bugzilla 12 Jun '24

12 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=47778 Bug ID: 47778 Summary: world of warcraft in game store browser crashes Product: Wine Version: 4.15 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: goin2mars(a)protonmail.com Distribution: --- Created attachment 65266 --> https://bugs.winehq.org/attachment.cgi?id=65266 backtrace from running in game wow browser opened when using shop feature wow browser : BlizzardBrowser.exe found in /home/me/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/UTILS -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 56650] New: Report on SELinux 'execheap' Issues with wine-preloader
by WineHQ Bugzilla 11 Jun '24

11 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56650 Bug ID: 56650 Summary: Report on SELinux 'execheap' Issues with wine-preloader Product: Wine Version: 9.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chplee(a)gmail.com Distribution: --- This report was prepared by ChatGPT. I'm sorry that my own ability is not enough to support such a large amount of code analysis, so I have to turn to ChatGPT. I'm filing this report because a lot of people are suffering from this problem. Please refer to: https://bugzilla.redhat.com/show_bug.cgi?id=2247299 ### Report on SELinux 'execheap' Issues with `wine-preloader` #### Introduction The `wine-preloader` program is a crucial part of the Wine software, which allows Windows applications to run on Unix-like operating systems. An issue has been identified where SELinux prevents `wine-preloader` from executing code in writable memory regions, raising security alerts related to 'execheap' accesses. This report identifies potential sources of the issue in the program and provides recommendations for modifications. #### Potential Issues Identified 1. **Memory Mapping and Protection Setup**: In `wine-preloader`, memory mapping is handled with protections set that could potentially include both write and execute permissions. This is particularly evident in the function calls to `wld_mmap`, where memory protection flags are set based on the segment flags parsed from ELF headers. ```c wld_mmap((void *)(l->l_addr + c->mapstart), c->mapend - c->mapstart, c->prot, MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); ``` Here, the `c->prot` can contain combinations of `PROT_READ`, `PROT_WRITE`, and `PROT_EXEC` based on the segment's flags. 2. **Dynamic Code Generation**: Dynamic generation or modification of code could potentially occur, though not explicitly shown in the code snippets provided, it could be inferred from the overall functionality where executable code may be modified or generated on-the-fly. 3. **Modifying Memory Protection Attributes**: The use of `wld_mprotect` to change the protection attributes of memory pages could lead to states where pages are both writable and executable. ```c wld_mprotect((caddr_t) (zero & ~page_mask), page_size, c->prot|PROT_WRITE); ``` Although this snippet aims to make pages writable temporarily, if combined inappropriately with executable flags elsewhere, it could trigger SELinux policies. #### Recommendations - **Restricting Memory Permissions**: Enforce strict separations between writable and executable pages. Modify the logic that sets memory protections to ensure that no memory page is both writable and executable at the same time. This can be achieved by adjusting the ELF segment loading routines to separate code and data segments clearly. - **Use of Memory Protection Changes**: Implement a clear two-step process for handling memory that needs to be executable: - Initially, set memory to writable to modify or generate code. - Once modifications are complete, change the memory protection to executable only (removing write permissions). - **Code Audit and Testing**: Conduct a thorough audit of the places where memory permissions are set. Test under a SELinux-enforced environment to ensure that the adjustments meet security policies without hindering functionality. - **SELinux Policy Adjustments**: If `wine-preloader` inherently requires certain operations that SELinux policies restrict, consider creating custom SELinux policy modules that allow specific actions while maintaining overall security. This should be done cautiously to avoid creating unnecessary security holes. #### Conclusion Adjustments to `wine-preloader` should focus on ensuring that memory regions are either writable or executable but never both. By adhering to security best practices and possibly adjusting SELinux policies, `wine-preloader` can function effectively without triggering security violations in SELinux environments. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 44210] New: GNUTLS_CIPHER_CHACHA20_POLY1305 is not work
by wine-bugs＠winehq.org 10 Jun '24

10 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=44210 Bug ID: 44210 Summary: GNUTLS_CIPHER_CHACHA20_POLY1305 is not work Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs(a)winehq.org Reporter: serg.chaplya(a)gmail.com Distribution: --- Hello! I've tried to run this tool (http://cryptopump.info/en/download) on my Ubuntu system. I got some error: fixme:secur32:schannel_get_cipher_algid unknown algorithm 23 fixme:secur32:schannel_get_mac_algid unknown algorithm 200 fixme:secur32:schannel_get_cipher_algid unknown algorithm 23 fixme:secur32:schannel_get_mac_algid unknown algorithm 200 fixme:secur32:schannel_get_cipher_algid unknown algorithm 23 fixme:secur32:schannel_get_mac_algid unknown algorithm 200 fixme:secur32:schannel_get_cipher_algid unknown algorithm 23 fixme:secur32:schannel_get_mac_algid unknown algorithm 200 I've found that this error is here: https://github.com/wine-mirror/wine/blob/master/dlls/secur32/schannel_gnutl… Because GNUTLS_CIPHER_CHACHA20_POLY1305 is not supported. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 10

[Bug 44985] New: BIAS FX: Blank window when running the app
by wine-bugs＠winehq.org 10 Jun '24

10 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=44985 Bug ID: 44985 Summary: BIAS FX: Blank window when running the app Product: Wine Version: 3.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: oxez911(a)gmail.com Distribution: --- Created attachment 61119 --> https://bugs.winehq.org/attachment.cgi?id=61119 term output Distribution: Debian sid Wine version: 3.6.0~sid (Using the wine-devel package from winehq.org) Description: Trying the BIAS FX standalone app (both in 32 and 64bit) result in a blank window (black or white, seems random..) Note: the trial can be downloaded free of change at https://www.positivegrid.com/bias-fx/ I attached a trace of what I saw in the terminal, I can provide more info if needed (I'm not sure what WINEDEBUG needed to be set at, I didn't tweak it) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 66

[Bug 56717] New: Clip Studio Paint 3.0 takes very long to load
by WineHQ Bugzilla 09 Jun '24

09 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56717 Bug ID: 56717 Summary: Clip Studio Paint 3.0 takes very long to load Product: Wine Version: 9.8 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- The problem is that it calls IDWriteFactory_GetSystemFontCollection very often, and this is kinda expensive on Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 6