diff options
author | Ken Sharp <Ken.Sharp@artifex.com> | 2025-04-01 14:06:56 +0100 |
---|---|---|
committer | Ken Sharp <Ken.Sharp@artifex.com> | 2025-04-01 14:06:56 +0100 |
commit | 86fb68cb077ae3cd3f77bd1a449032a1a440e2a2 (patch) | |
tree | f35b890e5b9cac3702c458c9bf0d814c69da88d0 /lib/zugferd.ps | |
parent | 74c5e2cb5bf82826a82f45e5d7bc510ae55ffc6d (diff) |
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