Bug 1110419 - wine crashes due to misuse of stack smashing detection
Summary: wine crashes due to misuse of stack smashing detection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: wine
Version: 20
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Andreas Bierfert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-17 15:28 UTC by Marcus Müller
Modified: 2015-04-05 14:29 UTC (History)
6 users (show)

Fixed In Version: wine-1.7.39-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-15 03:02:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
wine buf patch (1023 bytes, patch)
2015-01-23 16:37 UTC, Orion Poplawski
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Wine HQ 37953 0 None None None Never

Description Marcus Müller 2014-06-17 15:28:15 UTC
Description of problem:

Wine crashes with "*** stack smashing detected ***"

Version-Release number of selected component (if applicable):

1.7.19

How reproducible:

Happens for certain windows programs every time, for others never.

Steps to Reproduce:
1. run "wine WoTLauncher.exe", for example.

Actual results:

Wine crashes with "*** stack smashing detected ***"

Expected results:

Running flawlessly like the hand-built git version from winehq.org 

Additional info:

fedora builds wine with "-fstack-protector-strong", while the current git version of winehq.org builds without that GCC option.
compare: https://kojipkgs.fedoraproject.org//packages/wine/1.7.19/1.fc20/data/logs/i686/build.log 


this leads to false "stack smashing detected" program aborts, because wine actually has to mess with stack memory in order to make windows executables run.

I have confirmed that when building vanilla git wine with CFLAGS="-fstack-protector-strong" the same errors occur, and with CFLAGS="" everything works.

Comment 1 Marcus Müller 2014-06-17 15:41:10 UTC
By the way, I'm not saying this is not a wine bug; being incompatible with stack protection may as well be a bug. However, functionality-wise this is a regression, because known-to-work software stops working.

Comment 2 Andreas Bierfert 2014-06-20 14:25:24 UTC
Is this 'new' for you as of .19?

Comment 3 Marcus Müller 2014-06-20 16:50:57 UTC
(In reply to Andreas Bierfert from comment #2)
> Is this 'new' for you as of .19?

I have only been able to test it with .19, since both my FC19 and my FC20 are on .19 now; however, I have been able to verify that the current wine-git version works *without* -fstack-protector-strong, but doesn't with.

So this error occured when switching from FC19 to FC20, which didn't increase the wine version.

This seems to be a FC20-related issue. Compare 
https://bugzilla.redhat.com/show_bug.cgi?id=978763
and 
https://fedorahosted.org/fesco/ticket/1128

Comment 4 Orion Poplawski 2015-01-22 18:13:49 UTC
*** stack smashing detected ***: .wine/drive_c/Program Files/Adobe/Reader 10.0/Reader/AcroRd32.exe terminated

wine-core-1.7.34-2.fc21.i686

Comment 5 Orion Poplawski 2015-01-22 22:18:24 UTC
I've spent much of the afternoon trying to debug this to no avail.  Closest I got is that perhaps it is in this function:

MSVCRT_wint_t CDECL MSVCRT__fputwc_nolock(MSVCRT_wint_t wc, MSVCRT_FILE* file)
{
    MSVCRT_wchar_t mwc=wc;
    ioinfo *fdinfo;
    MSVCRT_wint_t ret;

    fdinfo = get_ioinfo_nolock(file->_file);

    if((fdinfo->wxflag&WX_TEXT) && !(fdinfo->exflag&(EF_UTF8|EF_UTF16))) {
        char buf[MSVCRT_MB_LEN_MAX];
        int char_len;

        char_len = MSVCRT_wctomb(buf, mwc);
        if(char_len!=-1 && MSVCRT__fwrite_nolock(buf, char_len, 1, file)==1)
            ret = wc;
        else
            ret = MSVCRT_WEOF;
    }else if(MSVCRT__fwrite_nolock(&mwc, sizeof(mwc), 1, file) == 1) {
        ret = wc;
    }else {
        ret = MSVCRT_WEOF;
    }

    return ret;
}

or something it calls.  But too many problems with running gdb/winedbg have prevented me from getting any further.

Comment 6 Michael Cronenworth 2015-01-22 22:26:48 UTC
This is a wild guess since I haven't run into this and don't have a means to reproduce it, but Orion, could you try adding a length check on char_len?

        char_len = MSVCRT_wctomb(buf, mwc);
+       if ( char_len > MSVCRT_MB_LEN_MAX )
+           char_len = MSVCRT_MB_LEN_MAX;

Comment 7 Orion Poplawski 2015-01-22 22:47:23 UTC
I'll try that.

WINEDEBUG=all seems to reveal:

34302.752:0009:trace:msvcrt:MSVCRT__isatty :fd (1)
34302.752:0009:trace:msvcrt:pf_printf_w Format is: L"\3577\6000\357e\6000\1150\773b\3b74j\ce24i"
34302.752:0009:trace:msvcrt:_lock (29)
34302.752:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000042): returning 0x139b08
34302.752:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,0000013f): returning 0x112d08
34302.753:000d:trace:file:wine_nt_to_unix_file_name L"\\windows\\system\\%1.dll" not found in /export/home/orion/.wine/dosdevices/c:/windows/system
34302.753:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x112d08): returning TRUE
34302.753:000d:warn:ntdll:NtQueryAttributesFile L"\\??\\C:\\windows\\system\\%1.dll" not found (c0000034)
34302.753:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x139b08): returning TRUE
34302.753:000d:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\%1.dll",0x34f650,(nil),(nil))
34302.753:000d:trace:file:RtlGetFullPathName_U (L"C:\\windows\\%1.dll" 520 0x34f404 (nil))
34302.753:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000034): returning 0x139a08
34302.754:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000138): returning 0x129f10
34302.754:000d:trace:file:wine_nt_to_unix_file_name L"\\windows\\%1.dll" not found in /export/home/orion/.wine/dosdevices/c:/windows
34302.754:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x129f10): returning TRUE
34302.754:000d:warn:ntdll:NtQueryAttributesFile L"\\??\\C:\\windows\\%1.dll" not found (c0000034)
34302.754:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x139a08): returning TRUE
34302.755:000d:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\system32\\%1.dll",0x34f650,(nil),(nil))
34302.755:000d:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\%1.dll" 520 0x34f404 (nil))
34302.755:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000046): returning 0x112e58
34302.755:0009:trace:seh:raise_exception code=80000101 flags=1 addr=0xf774abf0 ip=f774abf0 tid=0009

Comment 8 Orion Poplawski 2015-01-22 23:28:25 UTC
So, this is odd.  I rebuilt with this patch:

         char_len = MSVCRT_wctomb(buf, mwc);
+        if(char_len>MSVCRT_MB_LEN_MAX) {
+            char_len = MSVCRT_MB_LEN_MAX;
+            TRACE("char_len = %d\n", char_len);
+        }
+

and Adobe starts up okay now.  But I would have expected to see a message about char_len in the debug trace if this was actually doing anything, but I don't.

Comment 9 Michael Cronenworth 2015-01-23 05:04:49 UTC
Marcus,

I've created a F21 scratch build with the changes in comment 8.

http://koji.fedoraproject.org/koji/taskinfo?taskID=8704233

Could you install these packages and test your app?

Comment 10 Orion Poplawski 2015-01-23 16:34:04 UTC
I figured out why I wasn't seeing any messages - I also had the following:

--- wine-1.7.34/dlls/msvcrt/msvcrt.h.buf        2015-01-09 12:48:24.000000000 -0700
+++ wine-1.7.34/dlls/msvcrt/msvcrt.h    2015-01-22 12:06:11.800307738 -0700
@@ -47,7 +47,7 @@
 #define MSVCRT_I64_MAX    (((__int64)0x7fffffff << 32) | 0xffffffff)
 #define MSVCRT_I64_MIN    (-MSVCRT_I64_MAX-1)
 #define MSVCRT_UI64_MAX   (((unsigned __int64)0xffffffff << 32) | 0xffffffff)
-#define MSVCRT_MB_LEN_MAX 2
+#define MSVCRT_MB_LEN_MAX 6
 #ifdef _WIN64
 #define MSVCRT_SIZE_MAX MSVCRT_UI64_MAX
 #else

Which I thought I had tested, but that was before I realized that Adobe Reader was a 32-bit application.  I made that change because of this code:


INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch )
{
    return MSVCRT__wctomb_l(dst, ch, NULL);
}

int CDECL MSVCRT__wctomb_l(char *dst, MSVCRT_wchar_t ch, MSVCRT__locale_t locale)
{
    int len;

    MSVCRT__wctomb_s_l(&len, dst, dst ? 6 : 0, ch, locale);
    return len;
}

which seems to indicate that MSVCRT_wctomb() expects a buffer of length 6.  Looks like that should use MSVCRT_MB_LEN_MAX instead of "6".  I reported my proposed fix upstream (see linked bug).

I'll note that when I reverted the above change but kept the trace - the crash returned and I didn't see any messages, so perhaps the location was elsewhere.

Comment 11 Orion Poplawski 2015-01-23 16:37:00 UTC
Created attachment 983453 [details]
wine buf patch

Comment 12 Karel Zak 2015-01-30 22:06:27 UTC
(In reply to Michael Cronenworth from comment #9)
> I've created a F21 scratch build with the changes in comment 8.
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8704233

It still crashes with WoT launcher ;-(

Comment 13 Orion Poplawski 2015-02-04 16:36:32 UTC
Karel - can you test http://koji.fedoraproject.org/koji/taskinfo?taskID=8818633

Comment 14 Michael Cronenworth 2015-02-04 16:41:23 UTC
Here's a F20 scratch build if the F21 packages are not installable.

http://koji.fedoraproject.org/koji/taskinfo?taskID=8819056

Comment 15 Karel Zak 2015-02-05 13:04:03 UTC
I can test later this week (I'm out of my office now).

Comment 16 Karel Zak 2015-02-10 09:43:18 UTC
(In reply to Orion Poplawski from comment #13)
> Karel - can you test
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8818633

Your wine-1.7.35-3 works as expected. Thanks!

Comment 17 Fedora Update System 2015-02-10 15:29:31 UTC
wine-1.7.36-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/wine-1.7.36-1.fc21

Comment 18 Fedora Update System 2015-02-10 15:29:55 UTC
wine-1.7.36-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/wine-1.7.36-1.fc20

Comment 19 Fedora Update System 2015-02-13 02:21:51 UTC
Package wine-1.7.36-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing wine-1.7.36-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-1896/wine-1.7.36-1.fc20
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2015-02-15 03:02:10 UTC
wine-1.7.36-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-04-05 14:29:25 UTC
wine-1.7.39-1.fc20, wine-mono-4.5.6-1.fc20, mingw-wine-gecko-2.36-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.