Based on patch by Tomasz Buchert (http://bugzilla.maptools.org/show_bug.cgi?id=2480)
Description: fix for Debian bug #741451
tiffcp crashes when converting JPEG-encoded TIFF to a different
encoding (like none or lzw). For example this will probably fail:
tiffcp -c none jpeg_encoded_file.tif output.tif
The reason is that when the input file contains JPEG data,
the tiffcp code forces conversion to RGB space. However,
the output normally inherits YCbCr subsampling parameters
from the input, which leads to a smaller working buffer
than necessary. The buffer is subsequently overrun inside
cpStripToTile() (called from writeBufferToContigTiles).
Note that the resulting TIFF file would be scrambled even
if tiffcp wouldn't crash, since the output file would contain
RGB data intepreted as subsampled YCbCr values.
This patch fixes the problem by forcing RGB space on the output
TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
Author: Tomasz Buchert <tomasz.buchert@inria.fr>
* libtiff/tif_dir.c: TIFFSetField(): refuse to set negative values for
TIFFTAG_XRESOLUTION and TIFFTAG_YRESOLUTION that cause asserts when writing
the directory
* libtiff/tif_dirread.c: TIFFReadDirectory(): refuse to read ColorMap or
TransferFunction if BitsPerSample has not yet been read, otherwise reading
it later will cause user code to crash if BitsPerSample > 1
* libtiff/tif_getimage.c: TIFFRGBAImageOK(): return FALSE if LOGLUV with
SamplesPerPixel != 3, or if CIELAB with SamplesPerPixel != 3 or BitsPerSample != 8
* libtiff/tif_next.c: in the "run mode", use tilewidth for tiled images
instead of imagewidth to avoid crash
* tools/bmp2tiff.c: fix crash due to int overflow related to input BMP dimensions
* tools/tiff2pdf.c: fix crash due to invalid tile count (should likely be checked by
libtiff too). Detect invalid settings of BitsPerSample/SamplesPerPixel for CIELAB / ITULAB
* tools/tiffcrop.c: fix crash due to invalid TileWidth/TileHeight
* tools/tiffdump.c: fix crash due to overflow of entry count.
tag can return one channel, with the other two channels set to
NULL. The tiff2pdf code was expecting that other two channels
were duplicate pointers in the case where there is only one
channel. Detect this condition in order to avoid a crash, and
presumably perform correctly with just one channel.
sp->dec_codetab in LZWPreDecode (bug #2459)
* libtiff/tif_read.c: in TIFFReadBufferSetup(), avoid passing -1 size
to TIFFmalloc() if passed user buffer size is 0 (bug #2459)
* libtiff/tif_ojpeg.c: make Coverity happier (not a bug, #2459)
* libtiff/tif_dir.c: in _TIFFVGetField() and _TIFFVSetField(), make
Coverity happier (not a bug, #2459)
* libtiff/tif_dirread.c: in TIFFFetchNormalTag(), make Coverity happier
(not a bug, #2459)
* tools/tiff2pdf.c: close PDF file (bug #2479)
* tools/fax2ps.c: check malloc()/realloc() result (bug #2470)
* tools/tiffdump.c: detect cycle in TIFF directory chaining (bug #2463)
and avoid passing a NULL pointer to read() if seek() failed before (bug #2459)
* tools/tiffcrop.c: fix segfault if bad value passed to -Z option
(bug #2459) and add missing va_end in dump_info (#2459)
* tools/gif2tif.c: apply patch for CVE-2013-4243 (#2451)
Date: Thu, 18 Jul 2013 14:36:47 -0400
Here's a patch to correct an issue with creating G4-compressed PDFs.
The issue is caused by == being used to compare bitfields when only
one bit is intended to be compared. Some of the tiffs I have had both
T2P_CS_ICCBASED and T2P_CS_BILEVEL set; therefore, the current code
will fail, producing certain pages that are inverted.
The patch follows, and is also attached.
--David
be defective, then set it to zero before returning error in order
to terminate processing of truncated TIFF. Issue found and fix
suggested by Richard Nolde.
* tools/gif2tiff.c: fix possible OOB write (#2452, CVE-2013-4244)
* tools/tiff2pdf.c: terminate after failure of allocating
* tools/tiffinfo.c: Default various values fetched with
