gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

Laurent laurent at vromman.org
Sun Nov 29 02:10:17 CST 2009


On Sun, Nov 29, 2009 at 2:32 AM, Dan Kegel <dank at kegel.com> wrote:
> On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent at vromman.org> wrote:
>> -    pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes *
>> sizeof(GdiPath*));
>> -    pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath));
>> -    PATH_InitGdiPath(pStrokes[0]);
>> -    pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0,
>> pPath->numEntriesUsed * sizeof(INT));
>> -    pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0,
>> pPath->numEntriesUsed * sizeof(POINT));
>> -    pStrokes[0]->numEntriesUsed = 0;
>> +    pStrokes = NULL;
> ...
>
> Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment?

Yes, it would be. The fact is that makes a zero byte size HeapAlloc.
I'm not really sure how and why it is supposed to work in this case,
so I prefered to removed it. MSDN didn't help me to understand what is
a pointer to a zero byte size memory area, and how HeapReAlloc is
supposed to react then.

If you say it's ok, you're solution is way better.

pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes *
sizeof(GdiPath*)); can even be replaced by pStrokes =
HeapAlloc(GetProcessHeap(), 0, 0); It's useless to call sizeof if
numStrokes is 0.

If you are ok with all that, I can make a new patch based on your proposal.

> - Dan
>

Laurent



More information about the wine-devel mailing list