Hi,
I've worked on that bug today's evening and I found
a fairly simple fix. I'm quite confident that it fixes
the problem and does not break anything else (in any
case I understand the source of the problem). The upstream
may be interested in the fix.
The downside is that the result of JPEG to [none,lzw,lzma,...]
conversion will be encoded in RGB space, not subsampled YCrCb,
which may slightly increase output size. If you have questions,
do not hesitate.
I prepared a debdiff patch which I attach. It is written
as NMU, but you are free to modify it and incorporate
as a standard maintainer upload.
Cheers,
Tomasz
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2014-06-29 23:32:44.000000000 +0200
+++ tiff-4.0.3/debian/changelog 2014-10-28 18:32:27.000000000 +0100
@@ -1,3 +1,10 @@
+tiff (4.0.3-10.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Don't crash on JPEG => non-JPEG conversion (Closes: #741451)
+
+ -- Tomasz Buchert <tomasz.buch...@inria.fr> Tue, 28 Oct 2014 18:11:18 +0100
+
tiff (4.0.3-10) unstable; urgency=medium
* Remove libtiff4-dev, completing the tiff transition. Packages that
diff -Nru tiff-4.0.3/debian/patches/bug-741451.patch tiff-4.0.3/debian/patches/bug-741451.patch
--- tiff-4.0.3/debian/patches/bug-741451.patch 1970-01-01 01:00:00.000000000 +0100
+++ tiff-4.0.3/debian/patches/bug-741451.patch 2014-10-28 19:02:53.000000000 +0100
@@ -0,0 +1,34 @@
+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.buch...@inria.fr>
+
+--- tiff-4.0.3.orig/tools/tiffcp.c
++++ tiff-4.0.3/tools/tiffcp.c
+@@ -629,6 +629,11 @@ tiffcp(TIFF* in, TIFF* out)
+ TIFFSetField(out, TIFFTAG_PHOTOMETRIC,
+ samplesperpixel == 1 ?
+ PHOTOMETRIC_LOGL : PHOTOMETRIC_LOGLUV);
++ else if (input_compression == COMPRESSION_JPEG) {
++ /* RGB conversion was forced above
++ hence the output will be of the same type */
++ TIFFSetField(out, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
++ }
+ else
+ CopyTag(TIFFTAG_PHOTOMETRIC, 1, TIFF_SHORT);
+ if (fillorder != 0)
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series 2014-06-29 23:32:44.000000000 +0200
+++ tiff-4.0.3/debian/patches/series 2014-10-28 18:37:10.000000000 +0100
@@ -6,3 +6,4 @@
CVE-2013-4232.patch
CVE-2013-4244.patch
CVE-2013-4243.patch
+bug-741451.patch
