pdfjs-dist

7971 Commits

1 Branch

1804 Tags

126 MiB

Tree: 862342189f

Commit Graph

Author	SHA1	Message	Date
Rob Wu	e211c25f06	Improve robustness of stream parser (invalid length) When the parser finds a stream, it retrieves the Length from the stream dictionary and advances the lexer to the offset as specified in Length. If this Length is incorrect, the lexer could end up anywhere. When the lexer gets in an invalid state, it could throw errors. For example, in issue 6108, the lexer ends up inside the stream data. This stream has the ASCIIHexDecode filter, so all characters are made up from ASCII characters, and the lexer interprets it as a command token. Tokens cannot be longer than 127 bytes, so eventually 128 bytes are consumed and the lexer throws "Command token too long" error. Another possible error is "Illegal character: 41" when the lexer happens to end up at a ')' due to the length mismatch. These problems are solved by catching lexer errors and recovering the parser via the existing stream length detection branch.	10 years ago
Rob Wu	fd29bb0c57	Subtract start offset for xrefs in recovery mode Xref offsets are relative to the start of the PDF data, not to the start of the PDF file. This is clear if you look at the other code: - In the XRef's readXRefTable and processXRefTable methods of XRef, the offset of a xref entry is set to the bytes as given by a PDF file. These values are always relative to the start of the PDF file (%PDF-). - The XRef's readXRef method adds the start offset of the stream to Xref entry's offset: "stream.pos = startXRef + stream.start". Clearly, this line assumes that the entry offset excludes the start offset. However, when the PDF is parsed in recovery mode, the xref table is filled with entries whose offset is relative to the start of the stream rather than the PDF file. This is incorrect, and the fix is to subtract the start offset of the stream from the entry's byte offset. The manually created PDF file serves as a regression test. It is a valid PDF, except: - The integer to point to the start of the xref table and the %%EOF trailer are missing. This will activate recovery mode in PDF.js - Some junk was added before the start of the PDF file. This exposes the bad offset bug.	10 years ago

Author

SHA1

Message

Date

Rob Wu

e211c25f06

Improve robustness of stream parser (invalid length)

When the parser finds a stream, it retrieves the Length from the stream
dictionary and advances the lexer to the offset as specified in Length.
If this Length is incorrect, the lexer could end up anywhere.

When the lexer gets in an invalid state, it could throw errors. For
example, in issue 6108, the lexer ends up inside the stream data. This
stream has the ASCIIHexDecode filter, so all characters are made up from
ASCII characters, and the lexer interprets it as a command token. Tokens
cannot be longer than 127 bytes, so eventually 128 bytes are consumed
and the lexer throws "Command token too long" error.

Another possible error is "Illegal character: 41" when the lexer happens
to end up at a ')' due to the length mismatch.

These problems are solved by catching lexer errors and recovering the
parser via the existing stream length detection branch.

10 years ago

Rob Wu

fd29bb0c57

Subtract start offset for xrefs in recovery mode

Xref offsets are relative to the start of the PDF data, not to the start
of the PDF file. This is clear if you look at the other code:

- In the XRef's readXRefTable and processXRefTable methods of XRef, the
  offset of a xref entry is set to the bytes as given by a PDF file.
  These values are always relative to the start of the PDF file (%PDF-).

- The XRef's readXRef method adds the start offset of the stream to
  Xref entry's offset: "stream.pos = startXRef + stream.start".
  Clearly, this line assumes that the entry offset excludes the start
  offset.

However, when the PDF is parsed in recovery mode, the xref table is
filled with entries whose offset is relative to the start of the stream
rather than the PDF file. This is incorrect, and the fix is to subtract
the start offset of the stream from the entry's byte offset.

The manually created PDF file serves as a regression test. It is a valid
PDF, except:
- The integer to point to the start of the xref table and the %%EOF
  trailer are missing. This will activate recovery mode in PDF.js
- Some junk was added before the start of the PDF file. This exposes the
  bad offset bug.

10 years ago

1 Commits (862342189fb1911395d0cc43db083726203c4a88)