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
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.
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.
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.