add explicit masking with 0xff before casting
to unsigned char (make icc -check=conversions happy)
* libtiff/tif_predict.c: operate on unsigned datatypes when
computing/applying differences to avoid undefined behaviour of
signed types (C standard compliance)
by Roger Leigh posted to tiff list on Wed, 1 Jul 2015 15:58:20
+0100.
* cmake: Add extra warning flags. Patch #2 of 3 by Roger Leigh
posted to tiff list on Wed, 1 Jul 2015 15:58:20 +0100.
* cmake: Correct snprintf fallback for VS2015. Patch #1 of 3 by
Roger Leigh posted to tiff list on Wed, 1 Jul 2015 15:58:20 +0100.
libtiff mailing list on Mon, 22 Jun 2015 21:21:01 +0100. Several
corrections to ensure that the autotools build still works were
added by me. I have not yet tested the build using 'cmake' or
MSVC with 'nmake'.
add-on library.
* test/Makefile.am (JPEG_DEPENDENT_CHECK_PROG): raw_decode
requires JPEG support to compile. Use Automake conditional to
only include it when JPEG support is available.
definitions that configure produces, including for WIN64. Still
needs to be tested.
'lld' is not assured by the run-time DLLs and so GCC warns.
Add TIFF_SIZE_T and TIFF_SIZE_FORMAT to provide a type definition
and printf format specifier to deal with printing values of
'size_t' type. In particular, this was necessary for WIN64.
Added a configure test for if the system headers provide 'optarg'
(normal case) and block out the many explicit 'extern' statements
in the utilities. This was found to be necessary under Windows
when getopt is in a DLL and the symbols are already imported with
dllimport via standard header files.
TIFFReadRGBAImageOriented, TIFFSetCompressionScheme,
TIFFSwabArrayOfTriples, TIFFVGetFieldDefaulted, _TIFFCheckRealloc,
TIFFRasterScanline, TIFFSetErrorHandlerExt,
TIFFSetWarningHandlerExt, TIFFNumberOfDirectories,
TIFFCreateCustomDirectory, TIFFCreateEXIFDirectory,
TIFFWriteCustomDirectory, _TIFFRewriteField as recommended by
Roger Leigh and justified by use in libtiff tests, documentation,
and changelog notes. Also sorted symbol list and removed
duplicate entries.
CID 1306634: Integer handling issues (SIGN_EXTENSION)
Suspicious implicit sign extension: "img->samplesperpixel" with type
"unsigned short" (16 bits, unsigned) is promoted in
"img->col_offset * img->samplesperpixel" to type "int" (32 bits, signed),
then sign-extended to type "long" (64 bits, signed). If
"img->col_offset * img->samplesperpixel" is greater than 0x7FFFFFFF, the
upper bits of the result will all be 1.
Attached is a patch that adds a configure option to select the file I/O style
on Windows hosts.
It defaults to --enable-win32-io on all windows targets other than Cygwin and
to --disable-win32-io on Cygwin, and thus should be backwards-compatible.
This allows programs using the Unix file I/O style (such as Netpbm's tifftopnm)
to link against libtiff if configured for e.g. MinGW.
TIFFRGBAImageGet does not properly handle a non-zero col_offset in the
TIFFRGBAImage structure passed as the first argument. The current (incorrect)
behaviour depends upon the organization of the input tiff file as follows:
1. If the TIFF is stripped, col_offset is completely ignored.
2. If the TIFF is tiled, the image result is shifted to the left to the
nearest tile boundary. For example, if the tilewidth is 100, col_offset is
125, and requested width is 200, you get an image with pixels from 100 up to
300, not 125 up to 325 as expected.
This problem was reported in the mailing list previously as follows, but no
action was taken:
1. http://www.asmail.be/msg0054834339.html although Andrew is wrong about
tiled images working fine.
2. http://www.asmail.be/msg0054682793.html
An Ubuntu user noticed that tiffgt was not appropriately calling glFlush(),
which was causing tiffgt to open blank windows in some cases. I'm not sure
what the cases are, but my system happened to be one that saw blank windows,
and the one-line fix the user provided was sufficient to solve it in my case.
1. libtiffcrop-fix.patch fixes a small problem in tiffcrop, it seems it
was incorrectly using TIFFSetField instead of CopyField.
And in libtiff-correct-fax-scaling.patch we have some other changes:
2. I had to remove a check in main() that didn't allow maxPageWidth to
be bigger than pageWidth.
3. [ Omitted due to question on universality ]
4. the pagewidth variable was being set as the maxpagewidth instead,
which made all the calculations bad. This made sense when the check in
point 2 was in place, but not anymore. I've modified it so that
pagewidth is set with the specified pagewidth when maxpagewidth is
bigger.
5. The remaining lines of the patch - in exportMaskedImage() -
basically fix the scaling.
http://bugzilla.maptools.org/show_bug.cgi?id=2078#c9
The problem is that TIFF library attempts to write TIFF header as soon as the
tiff2pdf utility initializes the library. Fortunately, the library contains an
I/O abstraction feature, so there are no hardcoded writes to a file descriptor
anywhere. In particular, it appears that the utility's output suppression
feature can be used to suppress the initial write of the header.
There are a lot of code like this:
buflen=snprintf(buffer, sizeof(buffer), "%lu", (unsigned long)number);
written += t2pWriteFile(output, (tdata_t) buffer, buflen );
in tiff2pdf. This is seriously broken: when formatted string is larger than
buffer, snprintf return value is >= sizeof(buffer) [current standard] or -1
[legacy]. And in case of other errors, snprintf returns -1.
Both would result in reading unallocated memory and possible SIGSEGV (DoS).
I doubt it can be really exploitable (to begin with, in most cases buffer was
large enough and sprintf->snprintf change was pure paranoia, IMO), but /if/ you
decided previous code was not safe and snprintf is necessary, /then/ you MUST
check its return value.
There is a longstanding bug in the LZW decompressor in LibTIFF. It
fails to decode files that contain two consecutive CODE_CLEAR codes.
These are allowed by the LZW spec and the same data sequence is
correctly decoded by Acrobat if you wrap the data in a PDF file.
