Original source file: http://www.owasp.org/images/6/6c/Attacking_WCF_Web_Services-Brian_Holyfield.pdf Tested with svn r11689 and release 8.71, both affected. Command line used was: ghostscript -dSAFER -dBASE -dNOPAUSE -sDEVICE=png16m -r300 -sOutputFile=out-%d.png ~/Attacking_WCF_Web_Services-Brian_Holyfield.pdf The problem seems to be a null pointer call - this patch prevents the crash: Index: base/gxclrast.c =================================================================== --- base/gxclrast.c (revision 11689) +++ base/gxclrast.c (working copy) @@ -53,6 +53,7 @@ #include "gxshade4.h" #include "gsicc_manage.h" #include "gsicc.h" +#include "gxdevcli.h" extern_gx_device_halftone_list(); extern_gx_image_type_table(); @@ -1994,7 +1995,9 @@ case cmd_op_fill_rect >> 4: if (state.rect.width == 0 && state.rect.height == 0 && state.rect.x == 0 && state.rect.y == 0) { - code = (*dev_proc(tdev, fillpage))(tdev, &imager_state, &dev_color); + dev_proc_fillpage((*fillpage)); + fillpage = dev_proc(tdev, fillpage); + code = fillpage ? (*fillpage)(tdev, &imager_state, &dev_color) : 0; break; } case cmd_op_fill_rect_short >> 4:
Created attachment 6703 [details] specimen file Much reduced and decompressed example file. The file contains a single image XObject, and several inline images in an Indexed RGB space which resolve to pretty much entirely white. There seems to be no other complexity to speak of, but reducing the file further in Acrobat causes it to work....
We seem to encounter a 0 height and width rectangular fill, at x=y=0 during the course of a clip accumulation. A 0 width and height rectangle at 0,0 is special cased as a fillpage, but the clip accumulator doesn't have a fillpage method, so a crash ensues. This could be fixed by: 1) Not writing bogus fill rectangles. 2) Adding a fillpage method to the clip accumulator 3) Testing the fillpage method to see if its NULL before using it. Or, of course, I could be barking up completely the wrong tree, this not being my area of code. Probably this should go to Ray.
I agree that this needs to be straigtened out in the clist logic (the writing logic, probably). I'll have a look at it, but probably Ken's option 1 is the best -- not writing 0-size rectangles is the best. I don't really like the kloodge for the 'fillpage' case and may make that a unique direct function instead.
*** Bug 691823 has been marked as a duplicate of this bug. ***
BTW, this didn't fail for me at 300 dpi, but did at 600. The problem is caused by a clip region that is empty (a 0 width, 0 height rect). The 'tdev' when the clist reader gets a 'fill_rect' command is the clip_list_ accumulator, which understandably does not have a fillpage proc since all it is trying to do is to accumulate the pieces of the clip region. Ordinarily, these 0 width, 0 height rectangles would be written using the 'fill_rect_tiny' operation code (0x5c) rather that the 'fill_rect' opcode (0x30), so we wouldn't trip over the "special" (hacky) logic in fill_rect that interprets a 0 width, 0 height rectangle as 'fillpage'. The fix proposed will work, and is safe, so I will commit it, but also will look at why the logic that is writing the empty clip path is sometimes (rarely) using the fill_rect rather than fill_rect_tiny opcode. Note that in the sequence following the problematic opcode, we see: L]begin_clip(offset=53080): L]fill_rect_tiny 12(offset=53081): x=0 y=0 w=0 h=0 L]end_clip(offset=53082): Thus in another adjacent case, the clip path writing _is_ using the short form fill_rect_tiny opcode.
This was fixed by Robin's patch -- the "real" fix for fillpage is not needed urgently, just a cleanup.