Created attachment 6625 [details] ghostscript-jbig2-image-refcount.patch This Fedora bug applies to vanilla ghostscript-8.71: https://bugzilla.redhat.com/show_bug.cgi?id=621569 Here is a link to the input PDF document: https://bugzilla.redhat.com/attachment.cgi?id=334044 gs -dSAFER -dCompatibilityLevel=1.4 -q -dNOPAUSE \ -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr \ -sOutputFile=2009-41414141.pdf.pdf -dSAFER \ -dCompatibilityLevel=1.4 -c .setpdfwrite \ -f 2009-41414141.pdf I've attached the patch that fixes it for me.
Assigned to Marcos to see if this applies to HEAD. Also marking 'blocker' for now since it is a segfault.
I can reproduce it and I'll have a look. The patch appears to be more a workaround than a fix of the root cause.
xpdf and mupdf both crash on this as well. Adobe (Acrobat 8) and Apple Preview each have wrong output. I can't find a rip that prints this reasonably. Anyway: The first segment header appears to be corrupt: 0x0, 0x0, 0x0, 0x1, 0x40, 0x0, 0x0, 0x33, 0x33, 0x33, 0x13, 0x0, 0x0, 0xa (section numbers from the draft spec cited at http://jbig2dec.sourceforge.net/) 7.2.2 [0-3] 0x0 0x0 0x0 0x1, segment number 1. 7.2.3 [4] 0x40 - segment type = 0 (symbol dictionary), the page association field is 4 bytes long 7.2.4 [5] 0x0 - segment referred to segment count 7.2.6 [6-9] 0x0, 0x33, 0x33, 0x33 - page association is 3,355,443 (probably corrupt data) [10-13] 0x13, 0x0, 0x0, 0xa - segment data length 318767114! There is not enough data in the file so an underflow condition should be triggered but the code continues until the stream returns EOF at which point jbig2dec assumes a page image is available. There are several suspicious areas here that need study. The patch provided by Tim in comment #1 is fine as a work around solution.
(In reply to comment #3) > xpdf and mupdf both crash on this as well. Adobe (Acrobat 8) and Apple Preview > each have wrong output. I can't find a rip that prints this reasonably. > Anyway: > > The first segment header appears to be corrupt: > > 0x0, 0x0, 0x0, 0x1, 0x40, 0x0, 0x0, 0x33, 0x33, 0x33, 0x13, 0x0, 0x0, 0xa > > (section numbers from the draft spec cited at http://jbig2dec.sourceforge.net/) It may not be relevant, but my anti-virus software detects this file as infected with a trojan horse 'Dropper.Generic_c.AZV'. I wonder if the image is deliberately corrupted in order to serve as an infection mechanism.
As noted the file is corrupt and emulating Adobe is not possible. The file now errors out instead of crashing as of revision 11622.