On 08/09/15 21:06, Even Rouault wrote:
> Hi,
>
> A too huge number may cause the gmallocn() in Catalog::cachePageTree()
> to crash even if we call it with a low page number.
>
> Even
>
>+ // to avoid too huge memory allocations layer and avoid crashes
>+ // This is the maximum number of indirect objects as per
> ISO-32000:2008 (Table C-1)
Table C-1 is a list of minimum limits for 32-bit readers.
>+ // We could probably decrease that number again. PDFium for
>example uses 1 Mi
>+ else if (numPages > 8 * 1024 * 1024) {
>+ error(errSyntaxWarning, -1,
>+ "Page count ({0:d}) too big. Limiting number of
> reported pages to 8 Mi",
>+ numPages);
Instead of imposing an arbitrary limit we should just add a check for
gmallocn() returning NULL and print an error.
For broken PDFs that report an invalid size (see bug 85140) we could
check if the page count exceeds the number of objects in the XRef.
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
