summaryrefslogtreecommitdiff
path: root/lib/zugferd.ps
diff options
context:
space:
mode:
authorKen Sharp <Ken.Sharp@artifex.com>2025-04-01 14:06:56 +0100
committerKen Sharp <Ken.Sharp@artifex.com>2025-04-01 14:06:56 +0100
commit86fb68cb077ae3cd3f77bd1a449032a1a440e2a2 (patch)
treef35b890e5b9cac3702c458c9bf0d814c69da88d0 /lib/zugferd.ps
parent74c5e2cb5bf82826a82f45e5d7bc510ae55ffc6d (diff)
PDF interpreter - improve error handling with broken MatteHEADmaster
Bug #708343 "Infinite loop" This is not, in fact, a truly infinite loop but given 64-bit arithmetic it might take a long time. The cause of the problem is that the PDF file has an image which specifiesa /Matte, but teh Matte is specified as an indirect object and, probably due to the file being edited, the object in question is not a numeric array, it is an ObjStm. The error recovery path moves to reatign the image as a type 1 image (instead of a type 3 chroms-keyed image), but leaves the 'smask_stream' set, which causes us to convert that into a memory buffer and pass it into the image handling. Because the buffer is non-NULL we inspect both 'main_plane' and 'mask_plane' usage to determine if we have run out of data. But the image handling only sees one plabne, so it only sets the usage for a single plane. This leads to us using uninitlised data (the usage data), whch can have unpredictable results. Fixed here simply by setting smask_stream to NULL on error. At the same time, improved the error messaging and made the code exit properly if PDFSTOPONERROR is set.
Diffstat (limited to 'lib/zugferd.ps')
0 files changed, 0 insertions, 0 deletions