Bug 609948 - tiff2ps - double free or corruption
tiff2ps - double free or corruption
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libtiff (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Tom Lane
qe-baseos-daemons
http://bugzilla.maptools.org/show_bug...
: Reopened, Triaged
Depends On: 460322 1004408
Blocks: 580448
  Show dependency treegraph
 
Reported: 2010-07-01 07:10 EDT by Jan Ščotka
Modified: 2013-09-04 10:55 EDT (History)
6 users (show)

See Also:
Fixed In Version: libtiff-3.9.4-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 460322
Environment:
Last Closed: 2010-11-10 16:04:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Ščotka 2010-07-01 07:10:07 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2008-08-27 17:28:29 EDT ---

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

--- Additional comment from mmalik@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2009-01-09 03:09:14 EST ---

Issue also exist in libtiff-3.8.2-11.fc10

--- Additional comment from mvadkert@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2009-12-03 13:59:37 EST ---

Still there as of new upstream version 3.9.2 :-(

--- Additional comment from tgl@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 2 RHEL Product and Program Management 2010-07-01 07:23:15 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Tom Lane 2010-07-01 10:25:23 EDT
What was the point of cloning a closed bug, exactly?
Comment 4 Jan Ščotka 2010-07-01 16:07:05 EDT
Hi,
I do tier test of daemons component, and these test fail on RHEL6.0-20100622.1 (public beta2)
So for me it is a regression.

so I clone similar bug for this test because for me it look like same problem?
in jobid: 
http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=164860

testlog:
http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=15001561

test:
/CoreOS/libtiff/CVE-2006-3460ff
Comment 5 Jan Ščotka 2010-07-01 16:10:09 EDT
LOG:
:: 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
Comment 6 Tomas Hoger 2010-07-02 02:32:35 EDT
It seems the test was run using libtiff-3.9.2-3.el6 and not the latest libtiff-3.9.4-1.el6.  I believe changes in 3.9.4-1.el6 should make a difference here.
Comment 7 Tom Lane 2010-07-15 10:05:21 EDT
This should be fixed in snapshot 7 or later. Please retest.
Comment 8 Jan Ščotka 2010-07-15 10:44:15 EDT
Hi,
okay. I'll test it in snap7
Comment 9 RHEL Product and Program Management 2010-07-15 11:00:17 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 10 Jan Ščotka 2010-07-22 07:56:04 EDT
Repaired in snap 7
see RHTS test
http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=166547
Comment 11 releng-rhel@redhat.com 2010-11-10 16:04:45 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.