summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSebastian Rasmussen <sebras@gmail.com>2012-08-04 16:35:09 +0200
committerSebastian Rasmussen <sebras@gmail.com>2012-08-06 13:54:31 +0200
commit966ae9dc4ca3edce4ff592028baeb69fcebddeb7 (patch)
treeb20a87aeaac1ad785f51f21ae8e1cbc4e1af9435
parent16628b1419a260874f92b71263cc179c419f33b6 (diff)
downloadmupdf-966ae9dc4ca3edce4ff592028baeb69fcebddeb7.tar.xz
Fix bug where too many content stream operands cause eternal loop
Once enough operands were push on top of the operand stack an exception would be thrown. The exception handling ignored the exception, printed a warning and continued processing the content stream. Unfortunately the token was never consumed, so once the interpreter retried parsing the stream it encountered the same token again, causing the loop and thus a stack overflow. Now, make sure each token is consumed before throwing a new exception thereby breaking the eternal loop and letting pdfs with excessive operands be rendered, albeit with both errors and a warning.
-rw-r--r--pdf/pdf_interpret.c19
1 files changed, 12 insertions, 7 deletions
diff --git a/pdf/pdf_interpret.c b/pdf/pdf_interpret.c
index efc007e4..0ecb7893 100644
--- a/pdf/pdf_interpret.c
+++ b/pdf/pdf_interpret.c
@@ -2561,9 +2561,6 @@ pdf_run_stream(pdf_csi *csi, pdf_obj *rdb, fz_stream *file, pdf_lexbuf *buf)
{
do
{
- if (csi->top == nelem(csi->stack) - 1)
- fz_throw(ctx, "stack overflow");
-
/* Check the cookie */
if (csi->cookie)
{
@@ -2640,13 +2637,21 @@ pdf_run_stream(pdf_csi *csi, pdf_obj *rdb, fz_stream *file, pdf_lexbuf *buf)
break;
case PDF_TOK_INT:
- csi->stack[csi->top] = buf->i;
- csi->top ++;
+ if (csi->top < nelem(csi->stack)) {
+ csi->stack[csi->top] = buf->i;
+ csi->top ++;
+ }
+ else
+ fz_throw(ctx, "stack overflow");
break;
case PDF_TOK_REAL:
- csi->stack[csi->top] = buf->f;
- csi->top ++;
+ if (csi->top < nelem(csi->stack)) {
+ csi->stack[csi->top] = buf->f;
+ csi->top ++;
+ }
+ else
+ fz_throw(ctx, "stack overflow");
break;
case PDF_TOK_STRING: