Bug 695321 - Inefficient stream decoding by treating "hint" as "max"
Summary: Inefficient stream decoding by treating "hint" as "max"
Status: RESOLVED WORKSFORME
Alias: None
Product: MuPDF
Classification: Unclassified
Component: fitz (show other bugs)
Version: 1.4
Hardware: PC Windows 7
: P4 normal
Assignee: MuPDF bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-18 10:04 UTC by Brian Nixon
Modified: 2015-04-01 03:59 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Nixon 2014-06-18 10:04:42 UTC 
Following on from bug 695183...

There are still several stream types whose next_() function treats the "hint" as a maximum.  If these are in a chain with the Flate decoder, which asks how many bytes are available with a "hint" of 1, each call into zlib is again constrained to work one byte at a time.  (It looks like the DCT decoder can also lead to the same behaviour.)

Specifically I’ve seen the issue with PDF stream data encoded with Flate then encrypted with AES, but generally it could arise with any of the affected stream types.
Comment 1 Robin Watts 2015-04-01 03:59:01 UTC 
I believe this is fixed now. If not, can you please reopen with a file attached that shows the problem?

Thanks.