Blame SOURCES/ghostscript-cve-2018-16542.patch

b21b1b
From b661fd3bf2a7a8ba375131527551bd2834ad1abf Mon Sep 17 00:00:00 2001
b21b1b
From: Chris Liddell <chris.liddell@artifex.com>
b21b1b
Date: Thu, 23 Aug 2018 12:20:56 +0100
b21b1b
Subject: [PATCH] Bug 699668: handle stack overflow during error handling
b21b1b
b21b1b
When handling a Postscript error, we push the object throwing the error onto
b21b1b
the operand stack for the error handling procedure to access - we were not
b21b1b
checking the available stack before doing so, thus causing a crash.
b21b1b
b21b1b
Basically, if we get a stack overflow when already handling an error, we're out
b21b1b
of options, return to the caller with a fatal error.
b21b1b
---
b21b1b
 psi/interp.c | 7 ++++++-
b21b1b
 1 file changed, 6 insertions(+), 1 deletion(-)
b21b1b
b21b1b
diff --git a/psi/interp.c b/psi/interp.c
b21b1b
index 3e3aaaa..1ed7074 100644
b21b1b
--- a/psi/interp.c
b21b1b
+++ b/psi/interp.c
b21b1b
@@ -665,7 +665,12 @@ again:
b21b1b
     /* Push the error object on the operand stack if appropriate. */
b21b1b
     if (!ERROR_IS_INTERRUPT(code)) {
b21b1b
         /* Replace the error object if within an oparray or .errorexec. */
b21b1b
-        *++osp = *perror_object;
b21b1b
+        osp++;
b21b1b
+        if (osp >= ostop) {
b21b1b
+            *pexit_code = gs_error_Fatal;
b21b1b
+            return_error(gs_error_Fatal);
b21b1b
+        }
b21b1b
+        *osp = *perror_object;
b21b1b
         errorexec_find(i_ctx_p, osp);
b21b1b
     }
b21b1b
     goto again;
b21b1b
-- 
b21b1b
2.14.4
b21b1b