This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 583081 - Assorted libtiff failures on downsampled OJPEG input
Assorted libtiff failures on downsampled OJPEG input
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libtiff (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
abrt_hash:73aad165dad6d06762a2db1c7dd...
: Reopened
Depends On:
Blocks: CVE-2010-2595 CVE-2010-2596 CVE-2010-2597 CVE-2010-2598
  Show dependency treegraph
 
Reported: 2010-04-16 11:49 EDT by Nicolae Ghimbovschi
Modified: 2013-07-02 23:28 EDT (History)
5 users (show)

See Also:
Fixed In Version: libtiff-3.9.4-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 18:36:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
File: backtrace (12.66 KB, text/plain)
2010-04-16 11:49 EDT, Nicolae Ghimbovschi
no flags Details
Test file which causes convert to crash (320.79 KB, image/tiff)
2010-04-19 03:58 EDT, Nicolae Ghimbovschi
no flags Details

  None (edit)
Description Nicolae Ghimbovschi 2010-04-16 11:49:16 EDT
abrt 1.0.8 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: convert ./mail2fax_0_28809_1270566185.tif -o /dev/null
component: ImageMagick
executable: /usr/bin/convert
kernel: 2.6.32.11-99.fc12.x86_64
package: ImageMagick-6.5.4.7-3.fc12
rating: 4
reason: Process /usr/bin/convert was killed by signal 11 (SIGSEGV)
release: Fedora release 12 (Constantine)
Comment 1 Nicolae Ghimbovschi 2010-04-16 11:49:19 EDT
Created attachment 407138 [details]
File: backtrace
Comment 2 Pavel Alexeev 2010-04-18 14:13:23 EDT
Please provide file to reproduce.
Comment 3 Nicolae Ghimbovschi 2010-04-19 03:58:51 EDT
Created attachment 407502 [details]
Test file which causes convert to crash

run:

convert test2.tif out.pdf

will crash the ImageMagick.

Gimp fails to open this image, show the following message:
"Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software"

Though Evince, gThumb and Eye of Gnome opens it ok.
Comment 4 Pavel Alexeev 2010-05-04 06:38:40 EDT
Please try this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2160387
Comment 5 Nicolae Ghimbovschi 2010-05-04 08:38:26 EDT
(In reply to comment #4)
> Please try this build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2160387    

I tested with tiff file attached to this bug. 
https://bugzilla.redhat.com/attachment.cgi?id=407502

[ngh@localhost ~]$ gdb convert
GNU gdb (GDB) Fedora (7.1-18.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/convert...Reading symbols from /usr/lib/debug/usr/bin/convert.debug...done.
done.
(gdb) set args test.tif out.pdf
(gdb) run
Starting program: /usr/bin/convert test.tif out.pdf
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71ec56b in putcontig8bitYCbCr22tile (img=0x7fffffff65e0, cp=<value optimized out>, 
    x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, 
    h=<value optimized out>, fromskew=-119220, toskew=<value optimized out>, 
    pp=<value optimized out>) at tif_getimage.c:1857
1857				YCbCrtoRGB(cp[0], pp[0]);
(gdb) backtrace
#0  0x00007ffff71ec56b in putcontig8bitYCbCr22tile (img=0x7fffffff65e0, 
    cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, 
    w=<value optimized out>, h=<value optimized out>, fromskew=-119220, 
    toskew=<value optimized out>, pp=<value optimized out>) at tif_getimage.c:1857
#1  0x00007ffff71ee368 in gtStripContig (img=0x7fffffff65e0, raster=<value optimized out>, 
    w=<value optimized out>, h=2338) at tif_getimage.c:840
#2  0x00007ffff71f0841 in TIFFReadRGBAImageOriented (tif=0x638c50, rwidth=1653, 
    rheight=<value optimized out>, raster=0x7fffed0d3010, orientation=4, 
    stop=<value optimized out>) at tif_getimage.c:480
#3  0x00007fffedf99df2 in ReadTIFFImage (image_info=0x60d800, exception=0x604c00)
    at coders/tiff.c:1533
#4  0x00007ffff79fb9d6 in ReadImage (image_info=<value optimized out>, exception=0x604c00)
    at magick/constitute.c:579
#5  0x00007ffff79fbecb in ReadImages (image_info=0x609600, exception=0x604c00)
    at magick/constitute.c:868
#6  0x00007ffff76ad6eb in ConvertImageCommand (image_info=0x609600, argc=3, argv=0x6028d0, 
    metadata=0x0, exception=0x604c00) at wand/convert.c:581
#7  0x00007ffff771dc4d in MagickCommandGenesis (image_info=0x605400, 
    command=0x4007f8 <ConvertImageCommand@plt>, argc=3, argv=0x7fffffffe348, 
    metadata=<value optimized out>, exception=0x604c00) at wand/mogrify.c:165
#8  0x0000000000400975 in main (argc=3, argv=0x7fffffffe348) at utilities/convert.c:80
Comment 6 Pavel Alexeev 2010-05-04 14:04:39 EDT
I fill it upstream: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=16155
Comment 7 Pavel Alexeev 2010-05-08 08:12:44 EDT
Please see, ImageMajick team sai it is libtiff issue: http://www.imagemagick.org/discourse-server/viewtopic.php?p=58463#p58463

Reopen, reassign.
Comment 8 Tom Lane 2010-06-10 13:32:59 EDT
As of libtiff 3.9.2-3, the test image causes rgb2ycbcr to crash with what seems to be the same issue:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d9b53b in putcontig8bitYCbCr22tile (img=0x7fffffffd980, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, 
    toskew=<value optimized out>, pp=0x7ffff68e3372 "\b") at tif_getimage.c:1857
1857                            YCbCrtoRGB(cp[0], pp[0]);
(gdb) bt
#0  0x00007ffff7d9b53b in putcontig8bitYCbCr22tile (img=0x7fffffffd980, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, 
    toskew=<value optimized out>, pp=0x7ffff68e3372 "\b") at tif_getimage.c:1857
#1  0x00007ffff7d9d338 in gtStripContig (img=0x7fffffffd980, raster=<value optimized out>, w=<value optimized out>, h=2338) at tif_getimage.c:840
#2  0x00007ffff7d9f7c1 in TIFFReadRGBAImageOriented (tif=0x604570, rwidth=1653, rheight=<value optimized out>, raster=0x7ffff6e6b010, orientation=4, stop=<value optimized out>) at tif_getimage.c:480
#3  0x00000000004011e3 in tiffcvt (in=0x604570, out=<value optimized out>) at rgb2ycbcr.c:307
#4  0x0000000000401b3b in main (argc=2, argv=0x7fffffffe828) at rgb2ycbcr.c:121

So indeed it's not ImageMagick's fault.

Also, tiff2rgba crashes, but with a different stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d87c8b in TIFFYCbCrtoRGB (ycbcr=0x608cb0, Y=<value optimized out>, Cb=<value optimized out>, Cr=<value optimized out>, r=<value optimized out>, g=0x7fffffffe0a8, b=0x7fffffffe0a4) at tif_color.c:192
192             *b = ycbcr->clamptab[ycbcr->Y_tab[Y] + ycbcr->Cb_b_tab[Cb]];
(gdb) bt
#0  0x00007ffff7d87c8b in TIFFYCbCrtoRGB (ycbcr=0x608cb0, Y=<value optimized out>, Cb=<value optimized out>, Cr=<value optimized out>, r=<value optimized out>, g=0x7fffffffe0a8, b=0x7fffffffe0a4) at tif_color.c:192
#1  0x00007ffff7d9b51a in putcontig8bitYCbCr22tile (img=0x7fffffffe1c0, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, 
    toskew=<value optimized out>, 
    pp=0x7ffff68e2010 "\33Qo\\~\200Rbrr~\200_j\254\374~\200s\204\377\374~\200\221\223\374\377~\200\224\223\377\375~\200\225\230\375\377~\200\231\230\377\376~\200\231\232\376\377~\200\233\234\377\377~\200\235\237\377\377~\200\240\240\377\377~\200\243\243\376\376~\200\243\243\376\376~\200\243\244\376\377~\200\245\246\377\377~\200\241\240\377\377~\200\235\231\377\376~\200\227\226\376\377~\200\225\225\377\377~\200\212\212\377\377~\200\214\214\377\377~\200\214\214\377\377~\200\212\212\377\377~\200\203\203\376\377~\202\203\202\377\376~\202\203\204\376\377~\202\204\202\377\375~\202{|\376\376~\202~\200\377\377~\202\200\200\377\377~\202\200\177\377\377~\202\201\200\377\377~\200\200\177"...)
    at tif_getimage.c:1857
#2  0x00007ffff7d9d338 in gtStripContig (img=0x7fffffffe1c0, raster=<value optimized out>, w=<value optimized out>, h=2338) at tif_getimage.c:840
#3  0x00007ffff7d9f7c1 in TIFFReadRGBAImageOriented (tif=0x603940, rwidth=1653, rheight=<value optimized out>, raster=0x7ffff6e6b010, orientation=1, stop=<value optimized out>) at tif_getimage.c:480
#4  0x0000000000401839 in cvt_whole_image (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:401
#5  tiffcvt (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:519
#6  main (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:115

Also of note: tiff2ps gets an assert failure:

$ tiff2ps bug583081.tif >/dev/null
TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37679 (0x932f) encountered.
TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37680 (0x9330) encountered.
TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37681 (0x9331) encountered.
TIFFSetField: bug583081.tif: Unknown pseudo-tag 65538.
OJPEGSetupDecode: Warning, Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software.
tiff2ps: tif_ojpeg.c:848: OJPEGPostDecode: Assertion `sp->libjpeg_session_active!=0' failed.
Aborted
Comment 10 Tom Lane 2010-06-11 16:09:58 EDT
No, make that three bugs ...
http://bugzilla.maptools.org/show_bug.cgi?id=2209
I don't have a fix for this one, and am not going to try very hard since it's a "safe" failure mode.
Comment 11 Tomas Hoger 2010-06-15 05:42:19 EDT
Tom, have you looked at older tiff versions wrt this issue?  This seems to crash at least EL3 and EL4 64bit versions, though crashes don't seem related.
Comment 12 Tom Lane 2010-06-15 09:22:35 EDT
What I've been testing is builds of the older libtiff versions on my F-11 workstation, so there might be some small discrepancies from what you see on "real" EL3/4.  I did not see crashes from this particular test case on the older branches, but that doesn't mean they couldn't happen given other circumstances.  A large fraction of the other open libtiff bugs *do* crash the older builds for me.  My feeling is that the most prudent thing to do is apply as many of the 3.9.2 fixes to the older branches as can be made to fit.  In this particular case I found that the #2207 patch doesn't seem to be needed in EL4 but the #2208 one does.  Didn't look at the EL3 code yet.
Comment 13 Tomas Hoger 2010-06-16 05:35:11 EDT
(In reply to comment #12)
> What I've been testing is builds of the older libtiff versions on my F-11
> workstation, so there might be some small discrepancies from what you see on
> "real" EL3/4.  I did not see crashes from this particular test case on the
> older branches, but that doesn't mean they couldn't happen given other
> circumstances.

I did try EL4 libtiff built on F-12 x86_64 and it does not crash on this file, while real EL4 x86_64 dies on divide by zero.

It happens in TIFFVStripSize due to what seems to be a different compiler optimization wrt ycbcrsubsampling[2] array.  On real EL4, values are only stored in registers, while F-12 build uses memory.  TIFFGetField is called, but it does not change ycbcrsubsampling as TIFFFieldSet returns 0.  Hence following code uses whatever ycbcrsubsampling was initialized with, possibly 0 that leads to SIGPIPE in TIFFroundup calls.
Comment 14 Tomas Hoger 2010-06-16 08:10:05 EDT
Even stranger on EL3 x86_64:

Starting program: /usr/bin/tiff2rgba bz583081-test2.tif /dev/null
bz583081-test2.tif: Warning, unknown field with tag 513 (0x201) ignored.
bz583081-test2.tif: Warning, unknown field with tag 514 (0x202) ignored.
bz583081-test2.tif: Warning, unknown field with tag 37679 (0x932f) ignored.
bz583081-test2.tif: Warning, unknown field with tag 37680 (0x9330) ignored.
bz583081-test2.tif: Warning, unknown field with tag 37681 (0x9331) ignored.
TIFFSetField: bz583081-test2.tif: Unknown pseudo-tag 65538.
bz583081-test2.tif: Old-style JPEG compression support is not configured.

Breakpoint 3, gtStripContig (img=0x7fbfffa380, raster=0x2a95dd6010, w=1653, h=2338) at tif_getimage.c:661
661	        pos = ((row + img->row_offset) % rowsperstrip) * scanline;

(gdb) s
662	        (*put)(img, raster+y*w, 0, y, w, nrow, fromskew, toskew, buf + pos);

(gdb) print buf
$28 = (u_char *) 0x2a96c95010 ""

(gdb) print pos
No symbol "pos" in current context.

(gdb) print ((row + img->row_offset) % rowsperstrip) * scanline
$29 = 0

(gdb) print buf + ( ((row + img->row_offset) % rowsperstrip) * scanline )
$30 = (u_char *) 0x2a96c95010 ""

(gdb) s

Breakpoint 2, putRGBcontig8bittile (img=0x7fbfffa380, cp=0x2a96c92864, x=0, y=2337, w=2338, h=2338, fromskew=1653, 
    toskew=0, pp=0x921 <Address 0x921 out of bounds>) at tif_getimage.c:1006
1006	{
Comment 15 Tomas Hoger 2010-06-16 08:40:53 EDT
(In reply to comment #13)
> It happens in TIFFVStripSize due to what seems to be a different compiler
> optimization wrt ycbcrsubsampling[2] array.  On real EL4, values are only
> stored in registers, while F-12 build uses memory.  TIFFGetField is called, but
> it does not change ycbcrsubsampling as TIFFFieldSet returns 0.  Hence following
> code uses whatever ycbcrsubsampling was initialized with, possibly 0 that leads
> to SIGPIPE in TIFFroundup calls.    

It seems libtiff-subsampling.patch from bug #603703 should address this issue.
Comment 16 Tom Lane 2010-06-16 13:48:25 EDT
Huh, I can't duplicate a crash on this file using RHEL4-U7-RC2_http-AS-x86_64 on a beaker machine.  However, I do see assorted crashes on the test files of other open libtiff bugs.  Your description sounds like this particular problem might be associated with a read of uninitialized memory, so maybe the lack of reproducibility isn't so surprising.

With the 603703 patch and some other patches I've been working on for the other issues, I get no crashes on EL4.

The EL3 case looks really odd though ... what I would expect to get is "Sorry, requested compression method is not configured" followed by exit(1), but it looks like it's trying to plow ahead anyway ...
Comment 17 Fedora Update System 2010-06-23 00:14:32 EDT
libtiff-3.9.4-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc12
Comment 18 Fedora Update System 2010-06-23 00:14:52 EDT
libtiff-3.8.2-15.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libtiff-3.8.2-15.fc11
Comment 19 Fedora Update System 2010-06-23 00:15:06 EDT
libtiff-3.9.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc13
Comment 20 Fedora Update System 2010-06-24 12:29:52 EDT
libtiff-3.8.2-15.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2010-07-01 14:43:05 EDT
libtiff-3.9.4-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2010-07-05 18:00:42 EDT
libtiff-3.9.4-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Bug Zapper 2010-07-30 07:22:58 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Fedora End Of Life 2012-08-16 18:36:17 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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

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