Created attachment 9899 [details] log.txt Valgrind issues in the 64 bit build of ghostscript were found by fuzzing in pdf_image_plane_data (gdevpdfi.c:2020) while reading these files. See the attached log.txt for details. 1220.pdf.asan.21.248.pdf.pkmraw.300.0 1220.pdf.asan.21.248.pdf.ppmraw.300.0 1220.pdf.asan.21.248.pdf.ppmraw.72.0 1220.pdf.asan.21.248.ps.pkmraw.300.0 1220.pdf.asan.21.248.ps.ppmraw.300.0 1220.pdf.asan.21.248.ps.ppmraw.72.0
This one does give me valgrind errors, but all of them are in the JPEG2000 decoder which isn't entirely surprising as there are errors in the JPX images. On page 4 I see: openjpeg info: Main header has been correctly decoded. ==13149== Conditional jump or move depends on uninitialised value(s) ==13149== at 0x82A2447: opj_j2k_read_tile_header (j2k.c:7060) ==13149== by 0x82A5E6C: opj_j2k_decode_tiles (j2k.c:8755) ==13149== by 0x82A1283: opj_j2k_exec (j2k.c:6674) ==13149== by 0x82A6573: opj_j2k_decode (j2k.c:8971) ==13149== by 0x82A9E0A: opj_jp2_decode (jp2.c:1190) ==13149== by 0x82AE90F: opj_decode (openjpeg.c:525) ==13149== by 0x828F950: decode_image (sjpx_openjpeg.c:238) ==13149== by 0x829092E: s_opjd_process (sjpx_openjpeg.c:546) ==13149== by 0x8164973: sreadbuf (stream.c:815) ==13149== by 0x8164777: s_process_read_buf (stream.c:741) ==13149== by 0x819CC2F: image_file_continue (zimage.c:533) ==13149== by 0x8153F5C: do_call_operator (interp.c:86) ==13149== ==13149== Conditional jump or move depends on uninitialised value(s) ==13149== at 0x82A22BE: opj_j2k_read_tile_header (j2k.c:7063) ==13149== by 0x82A5E6C: opj_j2k_decode_tiles (j2k.c:8755) ==13149== by 0x82A1283: opj_j2k_exec (j2k.c:6674) ==13149== by 0x82A6573: opj_j2k_decode (j2k.c:8971) ==13149== by 0x82A9E0A: opj_jp2_decode (jp2.c:1190) ==13149== by 0x82AE90F: opj_decode (openjpeg.c:525) ==13149== by 0x828F950: decode_image (sjpx_openjpeg.c:238) ==13149== by 0x829092E: s_opjd_process (sjpx_openjpeg.c:546) ==13149== by 0x8164973: sreadbuf (stream.c:815) ==13149== by 0x8164777: s_process_read_buf (stream.c:741) ==13149== by 0x819CC2F: image_file_continue (zimage.c:533) ==13149== by 0x8153F5C: do_call_operator (interp.c:86) ==13149== ==13149== Conditional jump or move depends on uninitialised value(s) ==13149== at 0x82A177F: opj_j2k_get_marker_handler (j2k.c:6817) ==13149== by 0x82A1F63: opj_j2k_read_tile_header (j2k.c:7087) ==13149== by 0x82A5E6C: opj_j2k_decode_tiles (j2k.c:8755) ==13149== by 0x82A1283: opj_j2k_exec (j2k.c:6674) ==13149== by 0x82A6573: opj_j2k_decode (j2k.c:8971) ==13149== by 0x82A9E0A: opj_jp2_decode (jp2.c:1190) ==13149== by 0x82AE90F: opj_decode (openjpeg.c:525) ==13149== by 0x828F950: decode_image (sjpx_openjpeg.c:238) ==13149== by 0x829092E: s_opjd_process (sjpx_openjpeg.c:546) ==13149== by 0x8164973: sreadbuf (stream.c:815) ==13149== by 0x8164777: s_process_read_buf (stream.c:741) ==13149== by 0x819CC2F: image_file_continue (zimage.c:533) ==13149== openjpeg error: Marker is not compliant with its position openjpeg error: Failed to decode the codestream in the JP2 file openjpeg: failed to decode image! Returning to support as this isn't a pdfwrite problem.
I can confirm that we still get valgrind problems on page 4 in the open jpeg decoder.
Bisecting confirms that this bug was fixed by this commit 5 days before I was assigned the bug back in 2019: commit a0421f035fd418d27fd2df80b896d97d3d6e87ea (HEAD) Author: Sebastian Rasmussen <sebras@gmail.com> Date: Thu Jan 24 03:55:57 2019 +0100 Bug 694247: Do not confuse openjpeg input buffer usage with size. Previously s_opjd_accumulate_input() populated the openjpeg input data buffer and adjusted the buffer size and usage fields accordingly. The openjpeg callbacks for reading, skipping and seeking confused these two fields and used the buffer size instead of the buffer usage. This meant that there was a risk of reading uninitialized data.