+++ This bug was initially created as a clone of Bug #460322 +++
(in RHTS test: http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=15001561)
I'm not sure it it is same problem, or another, seems similar, but in RHTS test it causes:
:: tifftopnm testcase.03.tif ::
./runtest.sh: line 18:  4156 Killed                  tifftopnm $i &>/dev/null
	* exit code: 137

:: tiffinfo testcase.04.tif ::
./runtest.sh: line 18:  4174 Segmentation fault      (core dumped) tiffinfo $i &>/dev/null
	* exit code: 139

:: tiff2ps testcase.04.tif ::
./runtest.sh: line 18:  4177 Segmentation fault      (core dumped) tiff2ps $i &>/dev/null
	* exit code: 139

:: tifftopnm testcase.04.tif ::
./runtest.sh: line 18:  4180 Segmentation fault      (core dumped) tifftopnm $i &>/dev/null
	* exit code: 139


Description of problem:
When you run tiff2ps with quad-jpeg.tif you'll see an "double free or corruption" message.

Version-Release number of selected component (if applicable):
libtiff-3.8.2-9.fc8

How reproducible:
Always

Steps to Reproduce:
1. Go to http://www.remotesensing.org/libtiff/images.html .
2. Download the latest archive of test images ( ftp://ftp.remotesensing.org/pub/libtiff/pics-3.8.0.tar.gz ).
3. Unpack the file quad-jpeg.tif .
4. tiff2ps quad-jpeg.tif >& /dev/null
*** glibc detected *** double free or corruption (!prev): 0x0000000080013e50 ***
Aborted
5. echo $?
134
  
Actual results:
tiff2ps is aborted

Expected results:
tiff2ps finishes successfully

Additional info:
libtiff-3.6.1-12.el4_7.2 on RHEL4.7 is also affected

--- Additional comment from mmalik on 2008-08-27 11:13:25 EDT ---

libtiff-3.8.2-7.el5_2.2 on RHEL5.2 is also affected

--- Additional comment from tgl on 2008-08-27 13:03:50 EDT ---

AFAICT this is simply a known unsupported case.  tiff2ps reads the data using TIFFReadScanline(), which is stated in its manual page to not be usable for subsampled YCbCR data, which is what this image is.

It might be prudent to put a defense into TIFFReadScanline to make it report an error, instead of blindly proceeding and perhaps overrunning the caller's buffer (as indeed is happening here).  It's hard to tell however whether there are any other paths that would need to be plugged similarly.

--- Additional comment from tgl on 2008-08-27 14:40:18 EDT ---

Hmm, no, that analysis is too simplistic.  tiff2ps requests RGB output, so the library ought to be able to handle it.

This seems to be breakage from the CHECK_JPEG_YCBCR_SUBSAMPLING kluge: that is causing JPEGPreDecode to be invoked immediately during TIFFOpen, so it sets up tif_decoderow = JPEGDecodeRaw which is the case that won't work.  After that, the main program asks for RGB mode output, but this is never reflected in a change in the selected decoding routine.

I tried building with  --disable-check-ycbcr-subsampling, but that just moves the failure somewhere else: in this path, tif->tif_scanlinesize is calculated too soon and never updated, so JPEGDecode refuses to do anything.

The whole thing seems like a mess.  Going to contact upstream for advice...

--- Additional comment from tgl on 2008-08-27 17:28:29 EDT ---

RHEL-4's libtiff (3.6.1) has this issue as well.

--- Additional comment from mmalik on 2008-08-29 04:32:52 EDT ---

I think that tiffcmp suffers from the same problem.

$ tiffcmp -l quad-jpeg.tif quad-jpeg.tif
JPEGLib: Warning, Application transferred too many scanlines.
quad-jpeg.tif: EOF at scanline 0
*** glibc detected *** tiffcmp: double free or corruption (!prev): 0x085c1568 ***
======= Backtrace: =========
/lib/libc.so.6[0x990ac1]
/lib/libc.so.6(cfree+0x90)[0x9940f0]
/usr/lib/libtiff.so.3(_TIFFfree+0x1d)[0x6b341ad]
tiffcmp[0x8049d9a]
/lib/libc.so.6(__libc_start_main+0xe0)[0x93d390]
tiffcmp[0x8048881]
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0          [vdso]
0085f000-00880000 r-xp 00000000 fd:00 1720040    /usr/lib/libjpeg.so.62.0.0
00880000-00881000 rw-p 00020000 fd:00 1720040    /usr/lib/libjpeg.so.62.0.0
00908000-00923000 r-xp 00000000 fd:00 2195649    /lib/ld-2.7.so
00923000-00924000 r--p 0001a000 fd:00 2195649    /lib/ld-2.7.so
00924000-00925000 rw-p 0001b000 fd:00 2195649    /lib/ld-2.7.so
00927000-00a7a000 r-xp 00000000 fd:00 2195722    /lib/libc-2.7.so
00a7a000-00a7c000 r--p 00153000 fd:00 2195722    /lib/libc-2.7.so
00a7c000-00a7d000 rw-p 00155000 fd:00 2195722    /lib/libc-2.7.so
00a7d000-00a80000 rw-p 00a7d000 00:00 0 
00a82000-00aa9000 r-xp 00000000 fd:00 2195834    /lib/libm-2.7.so
00aa9000-00aaa000 r--p 00026000 fd:00 2195834    /lib/libm-2.7.so
00aaa000-00aab000 rw-p 00027000 fd:00 2195834    /lib/libm-2.7.so
00acf000-00ae1000 r-xp 00000000 fd:00 2196569    /lib/libz.so.1.2.3
00ae1000-00ae2000 rw-p 00011000 fd:00 2196569    /lib/libz.so.1.2.3
069d5000-069e0000 r-xp 00000000 fd:00 2196574    /lib/libgcc_s-4.1.2-20070925.so.1
069e0000-069e1000 rw-p 0000a000 fd:00 2196574    /lib/libgcc_s-4.1.2-20070925.so.1
06b04000-06b5a000 r-xp 00000000 fd:00 1729001    /usr/lib/libtiff.so.3.8.2
06b5a000-06b5c000 rw-p 00056000 fd:00 1729001    /usr/lib/libtiff.so.3.8.2
08048000-0804b000 r-xp 00000000 fd:00 1715304    /usr/bin/tiffcmp
0804b000-0804d000 rw-p 00002000 fd:00 1715304    /usr/bin/tiffcmp
085b0000-085d1000 rw-p 085b0000 00:00 0          [heap]
b7e00000-b7e21000 rw-p b7e00000 00:00 0 
b7e21000-b7f00000 ---p b7e21000 00:00 0 
b7f36000-b7f39000 rw-p b7f36000 00:00 0 
b7f3c000-b7f3d000 rw-p b7f3c000 00:00 0 
b7f3d000-b7f43000 r--s 00000000 fd:01 8905992    /home/mmalik/quad-jpeg.tif
b7f43000-b7f49000 r--s 00000000 fd:01 8905992    /home/mmalik/quad-jpeg.tif
bfe34000-bfe49000 rw-p bffeb000 00:00 0          [stack]
Aborted
$ echo $?
134
$

--- Additional comment from tgl on 2008-08-29 10:19:20 EDT ---

Yeah, it's a library problem --- it'd affect any of these programs that try to read the image data via TIFFReadScanline.

--- Additional comment from fedora-triage-list on 2008-11-26 06:07:29 EST ---


This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from fedora-triage-list on 2009-01-09 02:52:17 EST ---


Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

--- Additional comment from thoger on 2009-01-09 03:09:14 EST ---

Issue also exist in libtiff-3.8.2-11.fc10

--- Additional comment from mvadkert on 2009-07-03 21:41:42 EDT ---

tiffcmp segfault affects all RHEL:

*RHEL3*
[root@ia64-3as official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif
JPEGLib: Warning, Application transferred too many scanlines.
pics/quad-jpeg.tif: EOF at scanline 0
Segmentation fault

*RHEL4*
[root@s390-4as-8-v1 official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif
JPEGLib: Warning, Application transferred too many scanlines.
pics/quad-jpeg.tif: EOF at scanline 0
*** glibc detected *** double free or corruption (!prev): 0x00415a18 ***
Aborted

*RHEL5*
[root@s390x-5s-v1 official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif
JPEGLib: Warning, Application transferred too many scanlines.
pics/quad-jpeg.tif: EOF at scanline 0
*** glibc detected *** tiffcmp: double free or corruption (!prev): 0x000000008000e420 ***
Aborted

--- Additional comment from mvadkert on 2009-07-03 21:44:41 EDT ---

Affected packages from comment #10:
RHEL3 - libtiff-3.5.7-32.el3
RHEL4 - libtiff-3.6.1-12.el4_8.3
RHEL5 - libtiff-3.8.2-7.el5_3.3

--- Additional comment from fedora-triage-list on 2009-11-16 03:12:06 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from tgl on 2009-12-03 13:59:37 EST ---

Still there as of new upstream version 3.9.2 :-(

--- Additional comment from tgl on 2010-01-05 23:41:03 EST ---

I did some digging today and determined that the tiffcmp crash arises from a set of issues that are entirely independent of those confusing tiff2ps.  tiffcmp is trying to read the data without upsampling it to full size, and there are several bugs associated with that, which I have now filed upstream at
http://bugzilla.maptools.org/show_bug.cgi?id=2140
The tiff2ps code wants to perform upsampling, and the bugs in that are elsewhere.

--- Additional comment from fedora-triage-list on 2010-03-15 08:04:33 EDT ---


This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from tgl on 2010-06-10 12:57:06 EDT ---

As of libtiff-3.9.2-3, tiff2ps seems to work correctly with quad-jpeg.tif.  Also, tiffcmp doesn't crash, though it doesn't really work either; see upstream report 2140.