Bug 691532

Summary: jbig2dec segfault caused by new image reference counts
Product: Ghostscript Reporter: Tim Waugh <twaugh>
Component: JPX/JBIG2 encode/decodeAssignee: Henry Stiles <henry.stiles>
Status: RESOLVED FIXED    
Severity: blocker CC: henry.stiles, tor.andersson
Priority: P3    
Version: 8.71   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: ghostscript-jbig2-image-refcount.patch

Description Tim Waugh 2010-08-06 10:01:52 UTC 
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.
Comment 1 Ray Johnston 2010-08-06 14:56:07 UTC 
Assigned to Marcos to see if this applies to HEAD. Also marking 'blocker'
for now since it is a segfault.
Comment 2 Henry Stiles 2010-08-06 15:18:23 UTC 
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.
Comment 3 Henry Stiles 2010-08-09 05:38:16 UTC 
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.
Comment 4 Ken Sharp 2010-08-09 07:16:42 UTC 
(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.
Comment 5 Henry Stiles 2010-08-11 16:21:22 UTC 
As noted the file is corrupt and emulating Adobe is not possible.  The file now errors out instead of crashing as of revision 11622.