Bug #699707 "Security review bug - continuation procedures"

As a result of the recent security review, this bug was raised to go
through the PostScript interpreter looking for places where we exit the
'C' level and return control to PostScript. This is done when we need
to evaluate something in the PostScript environment, such as a transfer
function or a tint transform.

Because these functions are written in PostScript we need to run them
in the PostScript environment.

To do this we push the procedure (or at least 'a' procedure) onto the
exec stack and exit with an o_push_estack error. In many cases that's
all we need to do, but sometimes we want to return control back to the
'C' environment and, in some of those cases, we want to store some state
for the C code. We can't use the operand stack (because the PostScript
function will alter that) so we store stuff on the exec stack instead.

When we complete the C level, we should restore the exec stack, so if
we stored any state on it, we should remove it. Sometimes we were not
doing so if there was an error.

Generally this did not cause a problem, because in general on an error
we would stop. However if the error handler had been altered it was
possible we might carry on. 'Sometimes' that would mean we tried to
execute something which wasn't executable, and sometimes it might mean
that we tried to return to the C level, but without the expected
state on the exec stack.

This could lead to memory corruption and crashes.

This commit tries to find everywhere where we might end up leaving
extra items on the exec stack in the case of an error, and either
removes the required number of items from the exec stack or uses
whatever cleanup routine was established for the C code.

Its important to note that, in normal use, none of these could actually
cause a problem. This makes it hard to test. all the cases here I have
tested, though in many cases the only way I could produce an error was
by forcing an error return in the debugger. I suspect some error cases
simply aren't possible but its good practice to check the return codes
anyway, even if its only a theoretical problem.

1 files changed, 4 insertions, 1 deletions

diff --git a/psi/zht2.c b/psi/zht2.c
index 48d7dd3b8..60bd6567e 100644
--- a/psi/zht2.c
+++ b/psi/zht2.c
@@ -558,8 +558,11 @@ sethalftone_finish(i_ctx_t *i_ctx_p)
     if (pdht->components)
         pdht->order = pdht->components[0].corder;
     code = gx_ht_install(igs, r_ptr(esp - 1, gs_halftone), pdht);
-    if (code < 0)
+    if (code < 0) {
+        esp -= 4;
+        sethalftone_cleanup(i_ctx_p);
         return code;
+    }
     istate->halftone = esp[-2];
     esp -= 4;
     sethalftone_cleanup(i_ctx_p);