October 2026 - Wine-Bugs - list.winehq.org

[Bug 60562] New: winhttp silently truncates response header lines longer than 1459 bytes (breaks pre-signed S3 redirects)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60562 Bug ID: 60562 Summary: winhttp silently truncates response header lines longer than 1459 bytes (breaks pre-signed S3 redirects) Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs(a)list.winehq.org Reporter: jesper(a)jespersandstrom.se Target Milestone: --- Distribution: --- read_reply() in dlls/winhttp/request.c reads the status line and each response header line into a fixed stack buffer of MAX_REPLY_LEN (1460) bytes. read_line() copies at most that many bytes and discards the rest of the line, so a response header line longer than 1459 bytes is silently truncated. No error is returned to the caller. This is still the case in master as of 840a939ee5. Native WinHTTP accepts much longer header lines. The documented default for WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE is 64 KB for all headers combined, and WinHTTP defines ERROR_WINHTTP_HEADER_SIZE_OVERFLOW for responses that exceed it. Real-world impact: services that redirect to pre-signed AWS S3 / CloudFront URLs. When the signing credentials are temporary, the URL carries an X-Amz-Security-Token of about 1 KB, so the Location header goes over 1460 bytes. Signature parameters come last in these URLs, so the truncated Location loses X-Amz-SignedHeaders and X-Amz-Signature. After the redirect, S3 answers "400 Bad Request" with error code AuthorizationQueryParametersError ("Query- string authentication version 4 requires the X-Amz-Algorithm, X-Amz-Credential, X-Amz-Signature, X-Amz-Date, X-Amz-SignedHeaders, and X-Amz-Expires parameters"). Affected application: Adobe Lightroom Classic 15.6. Its Camera Raw engine downloads AI models from photos.adobe.io, which 302-redirects to such URLs. The People / Object / Reflection masking models fail with "some AI models failed to download", while the same version downloads them fine on Windows. Because the cut-off depends on the token length, some downloads in a session succeed and others fail. Steps to reproduce (no Adobe software needed): 1. Start a local HTTP server that answers GET / with status 200 and a Location header whose value is 2999 characters long. 2. From a Windows program running under wine, use WinHTTP to GET that URL (WinHttpOpen / WinHttpConnect / WinHttpOpenRequest / WinHttpSendRequest / WinHttpReceiveResponse), then read the header with WinHttpQueryHeaders(WINHTTP_QUERY_LOCATION) and print the returned length. Expected: 2999 characters Actual: 1449 characters. The 10-byte "Location: " prefix plus the 1449-byte value fill the 1460-byte buffer, including its terminating NUL. Raising the line limit in read_reply() to the native 64 KB makes the reproduction return the full value. With that change, Lightroom's model downloads succeed and the files are byte-identical to the same files downloaded on Windows. Disclosure: the root-cause analysis and the local test were done with the help of an AI assistant. Per the Clean Room Guidelines, no AI-written code is attached; the description above is meant to let a developer write the fix and the test independently. -- 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.

Oct. 23, 2026

[Bug 60561] Regression in 11.20: wine segfaults in ntdll.so at startup, even winecfg on a fresh prefix

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60561 Hado <hadoerdo1991(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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.

Oct. 22, 2026

[Bug 60561] New: Regression in 11.20: wine segfaults in ntdll.so at startup, even winecfg on a fresh prefix

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60561 Bug ID: 60561 Summary: Regression in 11.20: wine segfaults in ntdll.so at startup, even winecfg on a fresh prefix Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: hadoerdo1991(a)gmail.com Target Milestone: --- Distribution: --- Since Wine 11.20, every Wine process crashes immediately at startup with SIGSEGV (exit code 139). This happens even with `winecfg` on a brand-new prefix, so it is not application-specific. Wine 11.19 works fine on the same system. Tested (Kron4ek builds): - wine-11.20-amd64 -> crash - wine-11.20-amd64-wow64 -> crash - wine-11.20-staging-amd64-wow64 -> crash - wine-11.20-staging-tkg-amd64 / -wow64 -> crash - wine-11.19-staging-tkg-amd64-wow64 -> works Steps: WINEPREFIX=$HOME/test1120 wine winecfg dmesg: wine64[33896]: segfault at 0 ip 000079249e879589 sp 00007ffe70302d70 error 4 in ntdll.so[79589,79249e800000+a7000] gdb backtrace (no symbols) crashes at ntdll.so+0x79589; stack contains 0x7ffe0000 / 0x7ffe1000 (KUSER_SHARED_DATA region), suggesting the crash happens during early virtual memory setup. System: - Xubuntu 24.04, kernel 7.0.0-38-generic - MacBook Air 2012, Intel i5-3427U (Ivy Bridge), Intel HD 4000, 8 GB RAM - /dev/ntsync present Also reproduced on a second machine: - MacBook Pro Early 2015, Intel Core i5-5257U (Broadwell), 8 GB RAM - Ubuntu 24.04, Xorg, kernel 7.0.0-38-generic - wine-11.19-staging-tkg-amd64-wow64 -> works - wine-11.20-staging-tkg-amd64-wow64 -> crash I have not bisected yet, since building Wine on this machine is very slow, but I can test patches or specific builds if needed. -- 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.

Oct. 22, 2026

[Bug 60560] New: Initial WINEPREFIX setup hangs at "Updating, please wait..." dialog when the disk runs out of space

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60560 Bug ID: 60560 Summary: Initial WINEPREFIX setup hangs at "Updating, please wait..." dialog when the disk runs out of space Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: truiken(a)gmail.com Target Milestone: --- Distribution: --- $ mkdir -p /tmp/winetest $ sudo mount -t tmpfs -o size=250M tmpfs /tmp/winetest $ WINEPREFIX=/tmp/winetest/prefix winecfg Unclear whether the expected behavior should be a dialog alerting the user or output on stderr. -- 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.

Oct. 22, 2026

[Bug 60540] imgburn can't access Blu-ray writer anymore

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60540 --- Comment #3 from Zeb Figura <z.figura12(a)gmail.com> --- This seems to be a duplicate of bug 60527, although it's possible that one or both of these will have secondary bugs hidden behind that one that will need future work. -- 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.

Oct. 22, 2026

[Bug 60527] CUERipper does not work in Wine 11.20 - Drives not detected

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60527 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- Ah dammit, I messed up and missed one. This isn't the same as bug 60525; this one happens because it uses IOCTL_SCSI_PASS_THROUGH_DIRECT, and that has a pointer in it. This is going to be ugly to deal with. The architecturally nice thing to do would be to implement something like RtlCopyToUser(), but that would require WriteProcessMemory() and I don't think we want to rely on having that for anything but debugging purposes. -- 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.

Oct. 22, 2026

[Bug 60429] Anno 1800: Closes immediately after launch

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60429 --- Comment #4 from Philipp <philipp.kloke(a)web.de> --- Created attachment 82425 --> http://bugs.winehq.org/attachment.cgi?id=82425 Log with Wine 11.20 without dxvk - Anno 1800 does not work -- 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.

Oct. 22, 2026

[Bug 60429] Anno 1800: Closes immediately after launch

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60429 --- Comment #3 from Philipp <philipp.kloke(a)web.de> --- I disabled dxvk (in a new wineprefix I would have to reinstall the game). Please find the log attached. There is much more console output, but the visual result is - as expected, since it was caused by updating wine, not by updating dxvk - unchanged. It immediately closes after opening the main window. -- 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.

Oct. 22, 2026

[Bug 60559] New: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60559 Bug ID: 60559 Summary: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes) Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dinput Assignee: wine-bugs(a)list.winehq.org Reporter: winehqbmw(a)lsmod.de Target Milestone: --- Distribution: --- Created attachment 82424 --> http://bugs.winehq.org/attachment.cgi?id=82424 reproducer source Sudden Strike Gold (Steam 612300) crashes at startup with Proton 8.0 and later, with a NULL pointer read in Menu_Dll.dll. Proton 7.0 works a bit better, but has random crashes later. The crash happens when another process sends a message to the game window while the game is inside IDirectInputDevice::Acquire. Proton 8+ runs tabtip.exe, which sends WM_GETOBJECT to the focused window. In Wine, Acquire sends a message to dinput's internal input thread and waits for the reply. While it waits, it dispatches messages sent to the calling thread, so the game's window procedure runs from inside Acquire. The game doesn't expect that, and its startup ends up in a broken state. Unacquire behaves the same way. Native dinput doesn't do this. I checked on Windows XP SP3 with dinput versions 3, 5, 7 and 8, keyboard and mouse, foreground and background. The attached repro.c (produces repro.exe) sends WM_USER to its window from a second thread, calls Acquire, and prints how many times the window procedure ran during the call: Windows XP SP3: messages dispatched inside Acquire: 0 Wine 11.20 / Proton 10: messages dispatched inside Acquire: 1 The crash can be reproduced in plain Wine without tabtip.exe by running any program that repeatedly sends WM_GETOBJECT to the game window while it starts. -- 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.

Oct. 22, 2026

[Bug 55405] FreeCommander is crashing immediately after it starts, when Windows version is set above Windows XP

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55405 --- Comment #3 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Submitted a merge request: https://gitlab.winehq.org/wine/wine/-/merge_requests/12406 -- 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.

Oct. 22, 2026