Age | Commit message (Collapse) | Author |
|
In TIFFFillStrip, calls to TIFFReadBufferSetup may allocate large amounts of
memory. In this CL we do sanity checks on the claimed size of the raw strip
data before that happens, to prevent out-of-memory.
Bug: chromium:707431
Change-Id: I4e7c9a8630fad11d4f68a3ceccd71ffa511f4293
Reviewed-on: https://pdfium-review.googlesource.com/3811
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
CL list:
https://github.com/vadz/libtiff/commit/438274f938e046d33cb0e1230b41da32ffe223e1
https://github.com/vadz/libtiff/commit/43bc256d8ae44b92d2734a3c5bc73957a4d7c1ec
https://github.com/vadz/libtiff/commit/1044b43637fa7f70fb19b93593777b78bd20da86
https://github.com/vadz/libtiff/commit/9a72a69e035ee70ff5c41541c8c61cd97990d018
https://github.com/vadz/libtiff/commit/b4b41925115059b49f97432bda0613411df2f686
Bug: chromium:706349
Change-Id: I782156e7486919a62e25eeb95cb8699f1b2c5ee1
Reviewed-on: https://pdfium-review.googlesource.com/3374
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
This CL fixes the only caller to TIFFReadDirEntryData with potentially large
size so that we avoid big mallocs when we know we will fail. It does this as
follows:
- Avoid the unnecessary computations if datasize is very small. We don't want
to be slower in this case.
- If !isMapped(tif), we will Seek and Read. Check that ending position is
reachable. In the other case, do a simple check for out of bounds.
Bug: chromium:681311
Change-Id: Ia172d8b4d401753b7c8d5455dc1ada5335f6fa6b
Reviewed-on: https://pdfium-review.googlesource.com/3253
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Change-Id: If3f67767f738b7f23230ca8c37c9af2e31696e82
Reviewed-on: https://pdfium-review.googlesource.com/3117
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Tables should be freed before they are reassigned. This CL fixes the three
places where this is not happening.
BUG=694599
Change-Id: I4e7cf1a6354b1129ecaf7ddcc74d8a36ba289df7
Reviewed-on: https://pdfium-review.googlesource.com/2830
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Commit:
https://github.com/vadz/libtiff/commit/b5065f39ebc8b125aaa790f9003988c0d675f814
BUG=681305
Change-Id: I4e6c166f892bdac83b45e5518302bfd9cbcbd332
Reviewed-on: https://pdfium-review.googlesource.com/2571
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Upstream commits:
https://github.com/vadz/libtiff/commit/30c9234c7fd0dd5e8b1e83ad44370c875a0270ed
https://github.com/vadz/libtiff/commit/89406285f318ffad27af4b200204394b2ee6ba5e
BUG=690124
Change-Id: I8388ae37e94f4e62cd8f9688baf9cf5416348d0c
Reviewed-on: https://pdfium-review.googlesource.com/2558
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
tif_data and tif_cleanup are both set on the TIFFInit methods, see for
instance TIFFInitPixarLog. If PredictorSetupDecode fails, whatever was
filled on tif_data should be cleaned up. The previous leak fix from
PixarLogSetupDecode is no longer necessary.
BUG=683834
Change-Id: Ib7dec3fb8addd56fa20f2e85c4ee918222a5f97e
Reviewed-on: https://pdfium-review.googlesource.com/2432
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Using int64 to check whether uint32 operations have overflowed.
BUG=681300
Change-Id: I4470d34f2e5e61c0bf96f1c8587cdb7805afe87b
Reviewed-on: https://pdfium-review.googlesource.com/2355
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
The call may come from TIFFReadRGBAImageOriented, and there no cleanup
is done. So free the memory allocation on failure.
BUG=681301
Change-Id: I4ac7db03d18eddd3117649ca185dffdcc9189870
Reviewed-on: https://pdfium-review.googlesource.com/2252
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
If rb is allocated memory but p != q, then it will not be assigned to
sp->actable[m], so it will leak.
BUG=680520
Change-Id: Ib0b178b043b2a9821fb289d033ca0ab52e4cbe48
Reviewed-on: https://pdfium-review.googlesource.com/2176
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
Patch has been accepted upstream, see:
http://bugzilla.maptools.org/show_bug.cgi?id=2658
BUG=655008
Change-Id: I7ef69e6f71e66bd7e0a4d334c4f8e60ed02213d2
Reviewed-on: https://pdfium-review.googlesource.com/2174
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
The td_refblackwhite value is currently assigned without validation. This
may pose an issue as the image can specify the value as nan. This will cause
problems later when we use the nan in calcluations.
This CL validates each of the float values are not nan and if they are sets
them to the default provided by the TIFF spec v6.
BUG=chromium:632883
Change-Id: I17b01f744d3f5247c4bd3f42765a27b611dc7d8c
Reviewed-on: https://pdfium-review.googlesource.com/2151
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
This CL initializes the raw tif data to guard against unitialized memory access.
BUG=chromium:677377
Change-Id: If272fafacd996c2e93a41fb6e477661dc0c5492c
Reviewed-on: https://pdfium-review.googlesource.com/2150
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
This CL makes the fix to the bug equal to that which has now been
submitted upstream. Link:
https://github.com/vadz/libtiff/commit/fa6b22a5135fdeabe860097c04f298ca0ae7f2e1
Our original CL for fixing the bug:
https://codereview.chromium.org/2545723004/
BUG=657473
Change-Id: I52ae6a062ac07a0e20d0ba4ab823cbbf1d2b1ac1
Reviewed-on: https://pdfium-review.googlesource.com/2136
Commit-Queue: Nicolás Peña <npm@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
The method to create image can fail even after ycbcr has been set, so
the current way to release is not enough. TIFFRGBAImageEnd is safe in
that it checks for existence before deleting, and deletes whatever has
been created.
BUG=657473
Review-Url: https://codereview.chromium.org/2545723004
|
|
Fix potential buffer write overrun in PixarLogDecode() on corrupted/unexpected
images. The issue has been fixed in upstream (libtiff revision 1.44,
author: erouault, commitid: 2SqWSFG5a8Ewffcz, date: 2016-06-28 23:12:19 +0800).
This CL applies the official patch to tif_pixarlog.c.
BUG=chromium:654172
R=dsinclair@chromium.org, thestig@chromium.org
Review-Url: https://codereview.chromium.org/2453253003
|
|
The patch (https://codereview.chromium.org/2284063002) for Issue 618267
was insufficient. The integer overflow still could be triggered and could
lead to heap buffer overflow.
This CL strengthens integer overflow check in function _TIFFCheckRealloc.
BUG=chromium:654169
R=ochang@chromium.org, tsepez@chromium.org, dsinclair@chromium.org
Review-Url: https://codereview.chromium.org/2405693002
|
|
Depending on what ReadOK does it's possible for |dircount16| to be used without
being initialized. The read code calls back into PDFium specific code which then
calls into the stream reading code.
Initialize the value to be sure it is set.
BUG=chromium:651632
Review-Url: https://codereview.chromium.org/2389993002
|
|
overflow.
BUG=618267
Review-Url: https://codereview.chromium.org/2284063002
|
|
BUG=633387
Review-Url: https://codereview.chromium.org/2204793002
|
|
BUG=618164
Review-Url: https://codereview.chromium.org/2054993002
|
|
Enabling of XFA-Forms in crrev.com/1775173002 broke VS 2015 builds
because of a conflict between the lfind declaration in libtiff\tiffiop.h
and the one that ships with VS 2015. Defining HAVE_SEARCH_H for VS 2015
builds fixes this problem
BUG=440500,593996
R=thakis@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1781043005 .
|
|
R=jun_fang@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1563103002 .
|