Bug 696131: Detect some overflow conditions

When lexing a number, do NOT check for overflow. This causes
loss of data in some files. The current implementation matches
Acrobat.

When lexing a startxref offset, check for overflow. If found, throw
an error.

2 files changed, 10 insertions, 1 deletions

diff --git a/source/pdf/pdf-lex.c b/source/pdf/pdf-lex.c
index cc5bdd09..26a0f2e7 100644
--- a/source/pdf/pdf-lex.c
+++ b/source/pdf/pdf-lex.c
@@ -95,8 +95,13 @@ lex_number(fz_context *ctx, fz_stream *f, pdf_lexbuf *buf, int c)
 		case '.':
 			goto loop_after_dot;
 		case RANGE_0_9:
+			/* We deliberately ignore overflow here. We tried
+			 * code that returned INT_MIN/MAX as appropriate,
+			 * but this causes loss of data (see Bug695950.pdf
+			 * for an example). Tests show that Acrobat handles
+			 * overflows in exactly the same way we do (i.e.
+			 * 123450000000000000000678 is read as 678). */
 			i = 10*i + c - '0';
-			/* FIXME: Need overflow check here; do we care? */
 			break;
 		default:
 			fz_unread_byte(ctx, f);
diff --git a/source/pdf/pdf-xref.c b/source/pdf/pdf-xref.c
index 7c722c9c..6fa4770f 100644
--- a/source/pdf/pdf-xref.c
+++ b/source/pdf/pdf-xref.c
@@ -577,7 +577,11 @@ pdf_read_start_xref(fz_context *ctx, pdf_document *doc)
 				i ++;
 			doc->startxref = 0;
 			while (i < n && buf[i] >= '0' && buf[i] <= '9')
+			{
+				if (doc->startxref >= FZ_OFF_MAX/10)
+					fz_throw(ctx, FZ_ERROR_GENERIC, "startxref too large");
 				doc->startxref = doc->startxref * 10 + (buf[i++] - '0');
+			}
 			if (doc->startxref != 0)
 				return;
 			break;