[poppler] [PATCH] Catalog::getNumPages(): validate page count

[Jason Crain]

On 2015-09-08 07:43, Adrian Johnson wrote:
> 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.

By the way, bug 91353 is also about an invalid (fuzzed) PDF claiming 
millions of pages.  I thought about maybe walking the page tree to count 
pages if the count seems unreasonable but it didn't seem worth the 
effort.  I like your idea better.