- Wine-bugs - list.winehq.org

[Bug 21483] New: changed token security breaks .NET Framework SDK tools
by wine-bugs＠winehq.org 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=21483 Summary: changed token security breaks .NET Framework SDK tools Product: Wine Version: 1.1.33 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, some of Microsoft's tools from .NET Framework SDKs - namely managed debuggers (CLR) - stopped working after 1.1.33+ release. They seem to be very picky about object security. I bisected this one but technically this isn't a regression because Rob's token patches made Wine more correct - exposing another object security problem. --- snip --- $ git bisect bad bd56916f90e68632993a7275fe30a55a7efa222a is the first bad commit commit bd56916f90e68632993a7275fe30a55a7efa222a Author: Rob Shearman <robertshearman(a)gmail.com> Date: Mon Nov 16 20:11:06 2009 +0000 server: Extend get_token_user server call to also retrieve SIDs for the token's owner or primary group. :040000 040000 829f1543526675ae48f6fde8c8cedff74fd51797 7a77653291795c209ec529dd6660d52fc922a58c M dlls :040000 040000 57735b53b28db37ac4627dc009000e225175164a 4dcc1388cb136e559c06106632c08e8e610fe557 M include :040000 040000 4e83227cb0133c7e288a1e930461d4efe1130882 cf1c3539d6b3c91c854fa2b9b672f68ea601f639 M server --- snip --- "old" behaviour, where default process token was like this: Token owner -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group) Token user -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group) Token primary group -> S-1-5-32-544 "BUILTIN\Administrators" (alias) NtQueryInformationToken had the token owner info hard-coded (to SECURITY_INTERACTIVE_RID) while Rob's patches moved the actual query to wineserver. --- Basically the app code that verifies the security of created objects goes like this: - get SD from created object (event) handle -> GetKernelObjectSecurity( OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION) - get owner SID of SD -> GetSecurityDescriptorOwner() -> SID1 - get DACL of SD -> GetSecurityDescriptorDacl() - for each ACE from DACL (GetAce) -> SID2: check ACE SID against SD owner SID -> EqualSid( SID1, SID2) - match -> profit! not -> fail! --- snip --- ... 0023: create_event( access=001f0003, attributes=00000080, manual_reset=1, initial_state=0, objattr={rootdir=0014,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}}}},name=L"Global\\CorDBIPCSetupSyncEvent_36"} ) 0023: create_event() = 0 { handle=01c4 } ... 0025:trace:advapi:GetKernelObjectSecurity (0xc4,0x00000005,0x14ef40,0x00000050,0x33f7e8) 0025:trace:ntdll:NtQuerySecurityObject (0xc4,0x00000005,0x14ef40,0x00000050,0x33f7e8) 0025: get_security_object( handle=00c4, security_info=00000005 ) 0025: get_security_object() = 0 { sd_len=00000050, sd={control=00000037,owner={S-1-5-4},group=<not present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}}}} } 0025:trace:ntdll:RtlGetDaclSecurityDescriptor (0x14ef40,0x33f7c3,0x33f7ec,0x33f7c2) 0025:trace:ntdll:RtlGetAce (0x14ef60,0,0x33f7f0) 0025:trace:ntdll:RtlLengthSid sid=0x14ef54 0025: open_event( access=001f0003, attributes=00000002, rootdir=0034, name=L"Global\\CorDBIPCLSEventAvailName_36" ) 0025: open_event() = 0 { handle=00c8 } ... --- snip --- "new" behaviour, where default process token is now like this: Token owner -> S-1-5-32-544 "BUILTIN\Administrators" (alias) Token user -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group) Token primary group -> S-1-5-32-544 "BUILTIN\Administrators" (alias) --- snip --- ... 0024:trace:ntdll:NtOpenProcessTokenEx (0x1b0,0x00000008,0x00000000,0x318e6d0) 0024: open_token( handle=01b0, access=00000008, attributes=00000000, flags=00000000 ) 0024: open_token() = 0 { token=01b4 } ... 0024:trace:advapi:GetTokenInformation (0x1b4, TokenOwner, 0x184130, 20, 0x318e6e0): 0024:trace:ntdll:NtQueryInformationToken (0x1b4,4,0x184130,20,0x318e6e0) 0024: get_token_sid( handle=01b4, which_sid=00000004 ) 0024: get_token_sid() = 0 { sid_len=16, sid={S-1-5-32-544} } ... 0024: create_event( access=001f0003, attributes=00000080, manual_reset=1, initial_state=0, objattr={rootdir=0018,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}}}},name=L"Global\\CorDBIPCSetupSyncEvent_37"} ) 0024: create_event() = 0 { handle=01c8 } ... 0026:trace:advapi:GetKernelObjectSecurity (0xc8,0x00000005,(nil),0x00000000,0x33f7e8) 0026:trace:ntdll:NtQuerySecurityObject (0xc8,0x00000005,(nil),0x00000000,0x33f7e8) 0026: get_security_object( handle=00c8, security_info=00000005 ) 0026: get_security_object() = 0 { sd_len=00000058, sd={control=00000037,owner={S-1-5-4},group=<not present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}}}} } ... --- snip --- Using the "admins" sid (alias) as token user in server/token.c:token_create_admin() instead of current "interactive" sid fixes the problem. Though I don't know if this is the right thing to do. I hope I provided enough infos and let Alexandre handle it ;-) To get detailed token infos/dumps you might be interested in this little console app, from cygwin's Corinna Vinschen ;-) http://www.mail-archive.com/cygwin(a)cygwin.com/msg71800.html It might provide useful information when run under different security principals. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 19

[Bug 58368] New: Hammer++ texture window and browser broken
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=58368 Bug ID: 58368 Summary: Hammer++ texture window and browser broken Product: Wine Version: 10.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: luka05(a)bk.ru Distribution: --- Created attachment 78772 --> http://bugs.winehq.org/attachment.cgi?id=78772 Texture browser with severe artifacting, rendering it unusable The texture browser seems to have heavy artifacting, smearing everything as you scroll it. Also affects the face edit window, where the window that displays currently selected texture shows garbage instead. Happens with both DXVK and WineD3D. Tested in TF2 (64bit) and Source SDK 2013 Singleplayer (32bit) Hammer++ versions, affecting both OS: Arch Linux x86_64 Kernel: Linux 6.14.9-arch1-1 DE: KDE Plasma 6.3.5 WM: KWin (X11) CPU: Intel(R) Core(TM) i5-9400F (6) @ 4.10 GHz GPU: NVIDIA GeForce GTX 1050 Ti [Discrete] Hammer++ for TF2 download: https://github.com/ficool2/HammerPlusPlus-Website/releases/download/8869/ha… -- 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 45000] New: Ziphead by CNCD & Fairlight fails with GL_OUT_OF_MEMORY
by wine-bugs＠winehq.org 16 Nov '25

16 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=45000 Bug ID: 45000 Summary: Ziphead by CNCD & Fairlight fails with GL_OUT_OF_MEMORY Product: Wine Version: 3.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: arabek+wine(a)gmail.com Distribution: --- Created attachment 61129 --> https://bugs.winehq.org/attachment.cgi?id=61129 wine-staging ziphead.log (gzipped) A demoscene demo from 2015 fails to show any kind of output. I'm attaching the log. Expected result: running as under native Windows. Wine version: 3.6 & 3.6-staging (basically the same output, attached is the log from staging). -- 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 6

[Bug 59001] New: Compiling Wine with -march=znver4 prevents a crash with Deus Ex: Revision [Galaxy Audio]
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=59001 Bug ID: 59001 Summary: Compiling Wine with -march=znver4 prevents a crash with Deus Ex: Revision [Galaxy Audio] Product: Wine Version: 10.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Created attachment 79730 --> http://bugs.winehq.org/attachment.cgi?id=79730 Crash error I found a slightly weird bug. When running Deus Ex: Revision mod using regular WineHQ build (for Debian testing), it crashes during audio initialization [Galaxy Audio]. See attached screenshot. But when I compile Wine myself using this set up with explicit CPU architecture set to znver4: export CXXFLAGS="-march=znver4" export CFLAGS="$CXXFLAGS" export CROSSCFLAGS="$CXXFLAGS" It doesn't crash. My CPU is AMD Ryzen 9 7950X (Zen 4). I don't see anything clear in the log output. What can the issue be? And do you have any suggestions how to get more diagnostic for this? Build environment: gcc: 15.2.0 gcc-mingw-w64: 15.2.0 -- 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 58990] New: wine/tools/install-sh: No such file or directory
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=58990 Bug ID: 58990 Summary: wine/tools/install-sh: No such file or directory Product: Wine Version: 10.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: euloanty(a)live.com Distribution: --- make: /home/cqwrteur/toolchains_build/wine/tools/install-sh: No such file or directory /bin/sh: line 1: /home/cqwrteur/toolchains_build/wine/tools/install-sh: No such file or directory /bin/sh: line 1: /home/cqwrteur/toolchains_build/wine/tools/install-sh: No such file or directory make: *** [Makefile:1891: dlls/activeds.tlb/install-lib] Error 127 make: *** Waiting for unfinished jobs.... make: *** [Makefile:1627: dlls/acledit/install-lib] Error 127 make: *** [Makefile:1828: dlls/aclui/install-lib] Error 127 wine install failure -- 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 58797] New: Need for Speed Most Wanted (2005) crashes if launched with a path with spaces
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=58797 Bug ID: 58797 Summary: Need for Speed Most Wanted (2005) crashes if launched with a path with spaces Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: user.pecheniok(a)gmail.com Distribution: --- The path to the game contains the part "EA GAMES/Need for Speed Most Wanted/speed.exe". If I'm launching the game with a path as an argument(wine '~/Downloads/EA GAMES/Need for Speed Most Wanted/speed.exe'), it crashes with wine: Unhandled page fault on read access to 01DF0004 at address 0065AA27(or 2c, it differs) (thread 0144), starting debugger... but it works if I'm in the same folder and just use the exe name. This bug is, from what I observed, app-specific. Other apps I tried that have spaces in their paths do not crash because of that. -- 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 5

[Bug 58854] New: HDD health
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=58854 Bug ID: 58854 Summary: HDD health Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lars_martin4(a)hotmail.com Distribution: --- Created attachment 79519 --> http://bugs.winehq.org/attachment.cgi?id=79519 error message. https://hdd-health.software.informer.com/4.2/ -- 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

[Bug 58967] New: ConPTY: Child process inherits parent's std handles instead of connecting to the pseudoconsole
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

http://bugs.winehq.org/show_bug.cgi?id=58967 Bug ID: 58967 Summary: ConPTY: Child process inherits parent's std handles instead of connecting to the pseudoconsole Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: unxed(a)mail.ru Distribution: --- Created attachment 79673 --> http://bugs.winehq.org/attachment.cgi?id=79673 conpty_ping_test.c Observed behavior: When a process is created with the PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE attribute (using the ConPTY API), it incorrectly inherits the standard input/output handles (stdin/stdout/stderr) from its parent process. What is the expected behavior: The child process's standard handles should be connected to the pseudoconsole session provided by CreatePseudoConsole. Its output should be redirected to the ConPTY output pipe, not to the parent's stdout. This is the standard behavior on Windows. Steps to reproduce: 1. Compile the attached C program (conpty_ping_test.c). This program: a. Creates a pseudoconsole using CreatePseudoConsole. b. Creates pipes for the pseudoconsole's I/O. c. Launches a child process (ping.exe) using CreateProcessW with the PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE attribute set. d. Reads from the ConPTY output pipe and prints the data to its own stdout. 2. Run the compiled program from a terminal: wine conpty_ping_test.exe > conpty_ping_test.log Observed results: The host program's read loop terminates immediately, indicating that the ConPTY output pipe was closed without any data being written to it. Then, the full output of ping.exe is printed directly to the terminal. Example output: Pseudoconsole created successfully. Process 'ping 127.0.0.1 -n 4' started with PID: 1240 --- Start of process output --- [DEBUG] Pipe closed by the child process. Exiting read loop. --- End of process output --- Waiting for the child process to exit... Pinging 127.0.0.1 [127.0.0.1] with 32 bytes of data: PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. Ping statistics for 127.0.0.1 Packets: Sent = 4, Received = 0, Lost = 4 (100% loss) Process finished with exit code: 0 All resources have been freed. Exiting. This demonstrates that ping.exe's stdout was inherited from the host process (conpty_ping_test.c) rather than being attached to the pseudoconsole. This issue seems to stem from how the C-runtime (CRT) of the child process (ping.exe) initializes its standard handles. On Windows, the CRT detects the ConPTY session via the ConsoleHandle in the process parameters and connects its stdio to it by opening CONIN$ and CONOUT$. In Wine, it appears the CRT initialization code for msvcrt does not correctly handle this case and falls back to inheriting the parent's file handles. This is different from Wine's own conhost/tests/tty.c test, which works because the child process explicitly calls CreateFile("CONOUT$"), bypassing the problematic CRT initialization logic. The attached test case reproduces the scenario of a standard, unmodified console application like ping.exe. This bug makes the ConPTY API unusable for its primary purpose: capturing the I/O of external console applications. -- 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 57342] New: wine 9.20 is not available for several Debian/Ubuntu distributions in the WineHQ repositories
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=57342 Bug ID: 57342 Summary: wine 9.20 is not available for several Debian/Ubuntu distributions in the WineHQ repositories Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: memax(a)gmx.fr CC: dimesio(a)earthlink.net Distribution: --- Hello wine 9.20 is still not available in the WineHQ repositories for : - Ubuntu 24.04 (noble) - Ubuntu 22.04 (jammy) - Debian Testing (trixie) - Debian 12 (bookworm) However, it is available for: - Ubuntu 24.10 (oracular) - Ubuntu 20.04 (focal) - Debian 11 (bullseye) Any information on why? Thanks Regards -- 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 5

[Bug 57304] New: so like there is a bug when i download wine it says the following packages have unmet dependencies and i tried all way but never came down the solution pleasevremove the bug
by WineHQ Bugzilla 16 Nov '25

16 Nov '25

https://bugs.winehq.org/show_bug.cgi?id=57304 Bug ID: 57304 Summary: so like there is a bug when i download wine it says the following packages have unmet dependencies and i tried all way but never came down the solution pleasevremove the bug Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: packager Assignee: wine-bugs(a)winehq.org Reporter: mdboys3171(a)gmail.com Distribution: --- like i cant even download games please solve the following packages have unmet dependencies -- 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 5