Bug 698882

Summary: oss-fuzz 5490: Assert triggered in openjpeg
Product: MuPDF Reporter: Sebastian Rasmussen <sebastian.rasmussen>
Component: mupdfAssignee: MuPDF bugs <mupdf-bugs>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P4    
Version: unspecified   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: Minimized PDF from oss-fuzz.

Description Sebastian Rasmussen 2018-01-22 06:12:09 UTC 
Created attachment 14614 [details]
Minimized PDF from oss-fuzz.

When running 

build/sanitize/mutool draw -s t ./oss-fuzz-5490.pdf

an assert in openjpeg is triggered. I tried compiling openjpeg upstream 34dae137a9a8c04feaa9763ae7e09a86ecb10400 which is the commit mupdf uses at the moment. Running 

opj_decompress -i ./oss-fuzz-5490.pdf -o image.pgm 

does _not_ trigger the assert. So this must be researched further.
The mupdf draw output follows below:

error: cannot recognize xref format
warning: trying to repair broken xref
warning: repairing PDF document
warning: object missing 'endobj' token
error: no XObject subtype specified
error: no XObject subtype specified
error: no XObject subtype specified
error: no XObject subtype specified
error: no XObject subtype specified
error: no XObject subtype specified
error: zlib error: invalid distance too far back
warning: read error; treating as end of file
error: freetype: cannot load font: unknown file format
warning: ignored error when loading embedded font; attempting to load system font
error: no XObject subtype specified
warning: openjpeg warning: In SOT marker, TPSot (176) is not valid regards to the current number of tile-part (7), skipping

mutool: thirdparty/openjpeg/src/lib/openjp2/cio.c:552: opj_stream_get_number_byte_left: Assertion `p_stream->m_user_data_length >= (OPJ_UINT64)p_stream->m_byte_offset' failed.
Aborted
Comment 1 Sebastian Rasmussen 2018-09-05 17:35:57 UTC 
By extracting the j2k stream and attempting to decode this with the openjpeg command line too I can reproduce the crash. By doing the same decoding with the most recent version of openjpeg an error is printed instead. Thus I believe that upgrading openjpeg to a later version will fix this issue.
Comment 2 Sebastian Rasmussen 2018-09-13 17:26:40 UTC 
It is not only oss-fuzz 5490 that may be fixed by upgrading openjpeg, in addition 7673, 8129, 8269, 8866, 9379, 9380 and 9734 all seem to be fixable by updating openjpeg.
Comment 3 Sebastian Rasmussen 2018-09-21 11:49:07 UTC 
Fixed in

commit 2b06a50140b7eb81eb55dcc1547fee4e8842e697
Author: Sebastian Rasmussen <sebras@gmail.com>
Date:   Fri Sep 14 00:46:28 2018 +0800

    Update to OpenJPEG 2.3.0.
    
    There is a regression for 2325_-_JPX_image_with_padding_rejected.pdf.
    Object 3 in that document is a JPX-encoded image. Its EOC marker is
    preceded by two extra bytes of data, 0x80 0x80. This makes the file
    broken according to the JPEG 2000 specification.
    
    Acrobat Reader and the Kakadu JPX decoder accepts this file without
    issues, so OpenJPEG 2.1.0 added code to fix this (bug 226, commit
    005e75bdc). That fix detects exactly two bytes of 0x80 0x80, a rather
    brittle fix. Adding more padding or changing the padding byte values
    is not accepted. Adding more padding is acceptable to Acrobat Reader
    and Kakadu. An unrelated fix for another problem has since broken
    OpenJPEG's support for this broken image.