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

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