New issue
Advanced search Search tips

Issue 714502 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue pdfium:707
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

pdfium: GIF decoder's LZW implementation is broken

Project Member Reported by nigeltao@chromium.org, Apr 24 2017

Issue description

I'm eyeballing src/third_party/pdfium/core/fxcodec/lgif/fx_gif.cpp. Line 138 is:

} else if (code >= code_end) {

The >= should be ==. It was == as of 2016 December, but that was changed to >= by the 1-liner CL https://codereview.chromium.org/2542673004 aka commit 9be9c34866

As per https://www.w3.org/Graphics/GIF/spec-gif89a.txt Appendix F "Variable-Length-Code LZW Compression", under the "COMPRESSION" section, the clear code is 2**<code size>, the end_of_information code is <Clear code>+1, and "The first available compression code value is <Clear code>+2". Indeed, fx_gif.cpp's CGifLZWDecoder::InitTable says:

code_clear = 1 << code_size;
code_end = code_clear + 1;

Back to the spec, codes greater than (not equal to) code_end are valid codes whose semantics are not the same as code_end, whereas the fx_gif.cpp code treats them as equivalent.

I've only read the code, not run it. I don't know how to test this, manually or automatically. IIUC, PDF per se doesn't embed GIFs. PDFium's GIF code is only included "#if defined(PDF_ENABLE_XFA)", and I'm not familiar at all with XFA.

 
This is a dupe of https://bugs.chromium.org/p/pdfium/issues/detail?id=707

I'm not sure which bug tracker is authoratative.
Mergedinto: pdfium:707
Status: Duplicate (was: Untriaged)
Components: Internals>Plugins>PDF

Sign in to add a comment