Bug 2828 - tiff2rgba: Fax3DecodeRLE() large loop + _TIFFReadEncodedTileAndAllocBuffer large allocation
: tiff2rgba: Fax3DecodeRLE() large loop + _TIFFReadEncodedTileAndAllocBuffer l...
Status: RESOLVED LATER
: libtiff
default
: unspecified
: PC Linux
: P2 normal
: ---
Assigned To:
:
:
: migrated_to_gitlab
:
:
  Show dependency treegraph
 
Reported: 2018-11-21 03:12 by
Modified: 2019-10-01 14:21 (History)


Attachments
testcase (352 bytes, image/tiff)
2018-11-21 03:12, Petr Gajdos
Details


Note

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


Description From 2018-11-21 03:12:02
Created an attachment (id=880) [details]
testcase

Running tiff2rgba results in
1. large loop

        while (occ > 0) {

        }

(where occ is huge) inside Fax3DecodeRLE() with the repeating output:

[..]
Fax3DecodeRLE: Warning, Premature EOL at line 50 of tile 0 (got 0, expected
32).
Fax3DecodeRLE: Bad code word at line 51 of tile 0 (x 0).
Fax3DecodeRLE: Warning, Premature EOL at line 51 of tile 0 (got 0, expected
32).
Fax3DecodeRLE: Bad code word at line 52 of tile 0 (x 0).
[..]

2. perhaps excessive memory allocation 

Breakpoint 3, _TIFFReadEncodedTileAndAllocBuffer (tif=0x55555555b940, tile=0,
buf=0x7fffffffe0e0, bufsizetoalloc=1073742180, size_to_read=-1) at
tif_read.c:1076
1076        *buf = _TIFFmalloc(bufsizetoalloc);
(gdb) p bufsizetoalloc
$10 = 1073742180
(gdb)

which reminds me bug 2675.

See for details:
https://bugzilla.suse.com/show_bug.cgi?id=1003874
------- Comment #1 From 2018-11-21 04:32:16 -------
Hmm, this bug report is badly done, will report another one.
------- Comment #2 From 2018-11-21 04:42:39 -------
Actually no, all the above seem is true.

To add: 
1. this was with 4.0.10,
2. for completeness, tiffsplit shows the large allocation, too:

(gdb) bt
#0  _TIFFmalloc (s=1073742180) at tif_unix.c:311
#1  0x00005555555563cd in cpTiles (in=0x55555555c010, out=0x55555555ccf0) at
tiffsplit.c:266
#2  0x000055555555619e in tiffcp (in=0x55555555c010, out=0x55555555ccf0) at
tiffsplit.c:223
#3  0x000055555555545b in main (argc=2, argv=0x7fffffffe848) at tiffsplit.c:87
(gdb)
------- Comment #3 From 2018-11-21 05:37:06 -------
tiffinfo claims the tescase has a giant tile length:

$ tiffinfo poc.tif 
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 352 (0x160) encountered.
crash1.tif: Warning, Nonstandard tile length 268435545, convert file.
_TIFFVSetField: crash1.tif: Bad value 4 for "FillOrder" tag.
TIFFFetchNormalTag: Warning, ASCII value for tag "DocumentName" contains null
byte in value; value incorrectly truncated during reading due to implementation
limitations.
TIFFReadDirectory: Warning, Ignoring ColorMap since BitsPerSample tag not
found.
TIFFReadDirectory: Warning, TIFF directory is missing required
"StripByteCounts" field, calculating from imagelength.
TIFF Directory at offset 0x62 (98)
  Image Width: 32 Image Length: 32
  Tile Width: 32 Tile Length: 268435545
  Resolution: 0, 72 (unitless)
  Compression Scheme: CCITT RLE
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 32
  Planar Configuration: single image plane
  Page Number: 0-1
  DocumentName: not_kitty.tif
$
------- Comment #4 From 2019-10-01 14:21:26 -------
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets,
such as this one, have been migrated to the libtiff GitLab instance at
https://gitlab.com/libtiff/libtiff/issues .

The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is
the initial Bugzilla issue number.