Bug 1004408 - tiff2ps - double free or corruption
tiff2ps - double free or corruption
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libtiff (Show other bugs)
5.10
All Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Hracek
qe-baseos-daemons
http://bugzilla.maptools.org/show_bug...
: Reopened, Triaged
: 984240 (view as bug list)
Depends On: 460322
Blocks: 609948
  Show dependency treegraph
 
Reported: 2013-09-04 10:55 EDT by Alex Sersen
Modified: 2013-10-31 21:36 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 460322
Environment:
Last Closed: 2013-09-04 11:11:09 EDT
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 Alex Sersen 2013-09-04 10:55:42 EDT
+++ This bug was initially created as a clone of Bug #460322 +++

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 Milos Malik 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 Tom Lane 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 Tom Lane 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 Tom Lane on 2008-08-27 17:28:29 EDT ---

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

--- Additional comment from Milos Malik 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 Tom Lane 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 Bug Zapper 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 Bug Zapper 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 Tomas Hoger on 2009-01-09 03:09:14 EST ---

Issue also exist in libtiff-3.8.2-11.fc10

--- Additional comment from Miroslav Vadkerti 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 Miroslav Vadkerti 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 Bug Zapper 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 Tom Lane on 2009-12-03 13:59:37 EST ---

Still there as of new upstream version 3.9.2 :-(

--- Additional comment from Tom Lane 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 Bug Zapper 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 Tom Lane 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.

--- Additional comment from Bug Zapper on 2011-06-02 14:28:02 EDT ---


This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 Bug Zapper on 2011-06-27 10:00:11 EDT ---


Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.
Comment 1 Alex Sersen 2013-09-04 11:01:50 EDT
It looks there is the same problem on 3.8.2-18.el5_8

# 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): 0x08de1568 ***
======= Backtrace: =========
/lib/libc.so.6[0x4f1d35]
/lib/libc.so.6(cfree+0x59)[0x4f5d29]
/usr/lib/libtiff.so.3(_TIFFfree+0x1d)[0x7b7addd]
tiffcmp[0x8049d7a]
/lib/libc.so.6(__libc_start_main+0xdc)[0x49debc]
tiffcmp[0x8048861]
======= Memory map: ========
00469000-00484000 r-xp 00000000 fd:00 12714022   /lib/ld-2.5.so
00484000-00485000 r--p 0001a000 fd:00 12714022   /lib/ld-2.5.so
00485000-00486000 rw-p 0001b000 fd:00 12714022   /lib/ld-2.5.so
00488000-005df000 r-xp 00000000 fd:00 12714183   /lib/libc-2.5.so
005df000-005e1000 r--p 00157000 fd:00 12714183   /lib/libc-2.5.so
005e1000-005e2000 rw-p 00159000 fd:00 12714183   /lib/libc-2.5.so
005e2000-005e5000 rw-p 005e2000 00:00 0 
005e7000-0060e000 r-xp 00000000 fd:00 12716914   /lib/libm-2.5.so
0060e000-0060f000 r--p 00026000 fd:00 12716914   /lib/libm-2.5.so
0060f000-00610000 rw-p 00027000 fd:00 12716914   /lib/libm-2.5.so
00619000-0062b000 r-xp 00000000 fd:00 12716923   /lib/libz.so.1.2.3
0062b000-0062c000 rw-p 00011000 fd:00 12716923   /lib/libz.so.1.2.3
00d15000-00d20000 r-xp 00000000 fd:00 12716915   /lib/libgcc_s-4.1.2-20080825.so.1
00d20000-00d21000 rw-p 0000a000 fd:00 12716915   /lib/libgcc_s-4.1.2-20080825.so.1
00d23000-00d44000 r-xp 00000000 fd:00 15871934   /usr/lib/libjpeg.so.62.0.0
00d44000-00d45000 rw-p 00020000 fd:00 15871934   /usr/lib/libjpeg.so.62.0.0
00dfc000-00dfd000 r-xp 00dfc000 00:00 0          [vdso]
07b4a000-07ba1000 r-xp 00000000 fd:00 15885577   /usr/lib/libtiff.so.3.8.2
07ba1000-07ba3000 rw-p 00057000 fd:00 15885577   /usr/lib/libtiff.so.3.8.2
08048000-0804b000 r-xp 00000000 fd:00 15872094   /usr/bin/tiffcmp
0804b000-0804d000 rw-p 00002000 fd:00 15872094   /usr/bin/tiffcmp
08dd0000-08e12000 rw-p 08dd0000 00:00 0          [heap]
b7f75000-b7f78000 rw-p b7f75000 00:00 0 
b7f7b000-b7f7c000 rw-p b7f7b000 00:00 0 
b7f7c000-b7f82000 r--s 00000000 fd:00 15728708   /root/playground/quad-jpeg.tif
b7f82000-b7f88000 r--s 00000000 fd:00 15728708   /root/playground/quad-jpeg.tif
bff69000-bff7e000 rw-p bffe9000 00:00 0          [stack]
Aborted
[root@auto-i386-002 playground]# rpm -qa libtiff
libtiff-3.8.2-18.el5_8
Comment 2 Alex Sersen 2013-09-04 11:03:14 EDT
*** Bug 984240 has been marked as a duplicate of this bug. ***
Comment 3 Ondrej Vasik 2013-09-04 11:11:09 EDT
As RHEL-5 is in production phase 2 (and RHEL-5.11 will be production phase 3 and very limited), I strongly doubt it will ever get fixed in RHEL-5. Problem is fixed in RHEL-6. As this is not customer reported but just reported by internal QE, closing WONTFIX for RHEL-5. Feel free to reopen, if you have some justification which will increase the chances for RHEL-5 update.

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