Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
Wolfram Sang <wolfram(a)the-dreams.de> writes:
According to TestBot (#2851), all non-crashing Windows versions return 0.
Found while working on Bug 21012. Although this patch doesn't cure this bug, I think it is still worth adding the check because the pointer may come from the (always evil ;)) user-application.
Do you have an actual application that does this, or is this just hiding a Wine bug? -- Alexandre Julliard julliard(a)winehq.org
On 28 June 2010 12:26, Alexandre Julliard <julliard(a)winehq.org> wrote:
Wolfram Sang <wolfram(a)the-dreams.de> writes:
According to TestBot (#2851), all non-crashing Windows versions return 0.
Found while working on Bug 21012. Although this patch doesn't cure this bug, I think it is still worth adding the check because the pointer may come from the (always evil ;)) user-application.
Do you have an actual application that does this, or is this just hiding a Wine bug?
When running winedbg on bfginstaller.exe (trying to track down http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in the cursoricon.c code (line 771 -- http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9...): 767 /* pre-multiply by alpha */ 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) 769 { 770 unsigned int alpha = ptr[3]; 771 ptr[0] = ptr[0] * alpha / 255; 772 ptr[1] = ptr[1] * alpha / 255; 773 ptr[2] = ptr[2] * alpha / 255; 774 } The app itself does not crash there when not running without winedbg, but is generating an issue later on that does not make sense (which I am suspecting is a stack corruption issue, possibly triggered by this issue). I'm not sure if this is a wine bug, whether Wolfram's patch gets past the break triggered or whether it addresses the Big Fish Games issue. I'll test the patch tonight. - Reece
Reece Dunn <msclrhd(a)googlemail.com> writes:
When running winedbg on bfginstaller.exe (trying to track down http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in the cursoricon.c code (line 771 -- http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9...):
767 /* pre-multiply by alpha */ 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) 769 { 770 unsigned int alpha = ptr[3]; 771 ptr[0] = ptr[0] * alpha / 255; 772 ptr[1] = ptr[1] * alpha / 255; 773 ptr[2] = ptr[2] * alpha / 255; 774 }
The app itself does not crash there when not running without winedbg, but is generating an issue later on that does not make sense (which I am suspecting is a stack corruption issue, possibly triggered by this issue).
That's a DIB exception. Perfectly normal, and nothing whatsoever to do with the patch. -- Alexandre Julliard julliard(a)winehq.org
On 06/28/2010 01:44 PM, Reece Dunn wrote:
On 28 June 2010 12:26, Alexandre Julliard <julliard(a)winehq.org> wrote:
Wolfram Sang <wolfram(a)the-dreams.de> writes:
According to TestBot (#2851), all non-crashing Windows versions return 0.
Found while working on Bug 21012. Although this patch doesn't cure this bug, I think it is still worth adding the check because the pointer may come from the (always evil ;)) user-application.
Do you have an actual application that does this, or is this just hiding a Wine bug?
When running winedbg on bfginstaller.exe (trying to track down http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in the cursoricon.c code (line 771 -- http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9...):
767 /* pre-multiply by alpha */ 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) 769 { 770 unsigned int alpha = ptr[3]; 771 ptr[0] = ptr[0] * alpha / 255; 772 ptr[1] = ptr[1] * alpha / 255; 773 ptr[2] = ptr[2] * alpha / 255; 774 }
The app itself does not crash there when not running without winedbg, but is generating an issue later on that does not make sense (which I am suspecting is a stack corruption issue, possibly triggered by this issue).
I'm not sure if this is a wine bug, whether Wolfram's patch gets past the break triggered or whether it addresses the Big Fish Games issue.
I'll test the patch tonight.
- Reece
When debugging another application I got a page fault at the same position. You can either type "pass" or you can set |BreakOnFirstChance to false to prevent the debugger from running into that "first chance" page faults. That's expecially usefull when your application triggers the page fault very frequently. See http://www.winehq.org/docs/winedev-guide/dbg-config for more information. The application I were debugging has a stack corruption bug too but I don't think it's related. |
On 28/06/10 13:26, Alexandre Julliard wrote:
Wolfram Sang <wolfram(a)the-dreams.de> writes:
According to TestBot (#2851), all non-crashing Windows versions return 0.
Found while working on Bug 21012. Although this patch doesn't cure this bug, I think it is still worth adding the check because the pointer may come from the (always evil ;)) user-application.
Do you have an actual application that does this, or is this just hiding a Wine bug?
Nope, no application (yet). As said, I found this flaw while checking #21012. The accompanying tests, which sadly crash some windows versions, backup the changes AFAICS. I can repost after 1.2 if you prefer that. Regards, Wolfram
participants (4)
-
Alexandre Julliard -
Florian Köberle -
Reece Dunn -
Wolfram Sang