Age | Commit message (Collapse) | Author |
|
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
|
|
tif_pixarlog.c revision 1.45.
commitid: IX5L3QQ5Qtzcofcz
BUG=chromium:654172
Review-Url: https://codereview.chromium.org/2452293002
|
|
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
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2382723003
|
|
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
|
|
This CL moves the fxcrt code into the core/fxcrt directory. The only exception
was fx_bidi.h which was moved into core/fxcrt as it is not used outside of
core/.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1825953002 .
|
|
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=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1572523002 .
|
|
TBR=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1567063003 .
|
|
TBR=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1570443007 .
|
|
TBR=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1571523002 .
|
|
R=jun_fang@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1563103002 .
|