Summary: | A heap corruption in imagemask | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Igor Melichev <igor.melichev> |
Component: | General | Assignee: | Igor Melichev <igor.melichev> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- | |
Attachments: |
crash.bat
gsalloc.c (patched) trial patch1.txt |
Description
Igor Melichev
2005-06-15 01:49:30 UTC
I'm not sure how to fix it correctly. Placing both instances of gs_image_enum in the local memory should be preferrable, so probably zimage_data_setup must use i_ctx_p->pgs->memory instead iiemory. Also gs_image_begin_typed is hard to patch with adding the memory argument, because it is called from multiple places of the graphics library, so the change would distribute too wide and affects the device interface. So I thing patching zimage_data_setup and image_cleanup should be simpler. Created attachment 1448 [details]
temp2.ps
The sample document.
Created attachment 1449 [details]
crash.bat
A script to reproduce.
Created attachment 1450 [details]
gsalloc.c (patched)
A patched revision of gsalloc.c used to hook interesting allocations with MS
Developer Studio. The interesting allocation is i_alloc_struct called with
st_gx_image_enum. The instance address 0x18fd8b8 is hardcoded, but it may be
different in a different environment. The call ahppens with the image size
48x87 and after the allocation pinfo->id gets the value 97278, which may be
used to hook with a breakpoint at gdevvdrw.c ln 907 (in
gx_default_begin_typed_image after the call to *dev_proc(dev, begin_image) ).
Created attachment 1451 [details]
trial patch1.txt
The description of this bug includes some wrong statements, which are minor. When wrote it, I assumed that gs_image_enum is a subcalss of gx_image_enum_common_t. Actually it is not, and the mentioned instances have different types. The rest of the discription is correct. Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-June/005567.html |