|Summary:||tiff2ps - double free or corruption|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Jan Ščotka <jscotka>|
|Component:||libtiff||Assignee:||Tom Lane <tgl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||qe-baseos-daemons|
|Version:||6.0||CC:||borgan, hhorak, mmalik, mvadkert, syeghiay, thoger|
|Target Milestone:||rc||Keywords:||Reopened, Triaged|
|Fixed In Version:||libtiff-3.9.4-1.el6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-11-10 21:04:45 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||460322, 1004408|
Description Jan Ščotka 2010-07-01 11:10:07 UTC
+++ 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 firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org 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 email@example.com on 2008-08-27 17:28:29 EDT --- RHEL-4's libtiff (3.6.1) has this issue as well. --- Additional comment from firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org on 2009-01-09 03:09:14 EST --- Issue also exist in libtiff-3.8.2-11.fc10 --- Additional comment from email@example.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 firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org on 2009-12-03 13:59:37 EST --- Still there as of new upstream version 3.9.2 :-( --- Additional comment from email@example.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 firstname.lastname@example.org 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 email@example.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 11:23:15 UTC
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 14:25:23 UTC
What was the point of cloning a closed bug, exactly?
Comment 4 Jan Ščotka 2010-07-01 20:07:05 UTC
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 20:10:09 UTC
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 06:32:35 UTC
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 14:05:21 UTC
This should be fixed in snapshot 7 or later. Please retest.
Comment 8 Jan Ščotka 2010-07-15 14:44:15 UTC
Hi, okay. I'll test it in snap7
Comment 9 RHEL Product and Program Management 2010-07-15 15:00:17 UTC
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 11:56:04 UTC
Repaired in snap 7 see RHTS test http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=166547
Comment 11 firstname.lastname@example.org 2010-11-10 21:04:45 UTC
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.