AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2014.11.19 22:38 "[Tiff] libtiff release pending?", by Bob Friesenhahn
2014.11.19 22:48 "Re: [Tiff] libtiff release pending?", by Lee Howard
2014.11.19 23:09 "Re: [Tiff] libtiff release pending?", by Bob Friesenhahn
2014.11.19 23:07 "Re: [Tiff] libtiff release pending?", by Even Rouault
2014.11.19 23:14 "Re: [Tiff] libtiff release pending?", by Bob Friesenhahn
2014.11.19 23:23 "Re: [Tiff] libtiff release pending?", by Even Rouault
2014.11.19 23:34 "Re: [Tiff] libtiff release pending?", by Bob Friesenhahn
2014.11.19 23:40 "Re: [Tiff] libtiff release pending?", by Even Rouault
2014.11.19 23:59 "Re: [Tiff] libtiff release pending?", by Bob Friesenhahn
2014.12.06 18:29 "Re: [Tiff] libtiff test suite fails GCC Address Sanitizer", by Even Rouault

2014.12.06 18:29 "Re: [Tiff] libtiff test suite fails GCC Address Sanitizer", by Even Rouault

Le samedi 06 décembre 2014 17:53:13, Bob Friesenhahn a écrit:

> FYI, I just compiled libtiff CVS with Address Sanitizer
> (-fsanitize=address) and see that three of the tests (via 'make
> check') fail due to heap-buffer-overflow. It seems like it might be
> due to an off-by-one bug or at least it is accessing one beyond the
> end of an array. This is pretty serious and should be fixed prior to
> a release.
>
> The test suite log file is attached.

Bob,

I could also reproduce it, but the output of address sanitizer isn't really helpfull to locate the issue.

I tried with Valgrind, whom I'm much more familar, and whose output it is much clearer:

FAIL: tiffcp-thumbnail.sh
=========================

$ LD_LIBRARY_PATH=libtiff/.libs valgrind /home/even/libtiff/cvs/build/tools/.libs/thumbnail o-tiffcp-thumbnail-in.tif o-tiffcp-thumbnail-out.tif

[...]
==10871== Invalid read of size 1

==10871==    at 0x4025A8: setrow (thumbnail.c:520)
==10871==    by 0x402735: setImage1 (thumbnail.c:554)
==10871==    by 0x4027EF: setImage (thumbnail.c:564)
==10871==    by 0x4029B0: generateThumbnail (thumbnail.c:601)
==10871==    by 0x4014CF: main (thumbnail.c:120)
==10871==  Address 0x5f5574c is 0 bytes after a block of size 3,020 alloc'd
==10871==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==10871==    by 0x4E8D06F: _TIFFmalloc (tif_unix.c:263)
==10871==    by 0x4028FD: generateThumbnail (thumbnail.c:588)
==10871==    by 0x4014CF: main (thumbnail.c:120)

Unfortunately I can't make sense of the code of thumbnail.c, so I'm happy to leave it to you. Or we can open a Bugzilla issue about that. I've never used before this thumbnail utility. It is weird that it outputs so many fprintf(stderr,) as part of its normal execution.

FAIL: tiffcrop-doubleflip-miniswhite-1c-1b.sh
=============================================

Also reproduced in Valgrind

$ LD_LIBRARY_PATH=libtiff/.libs valgrind tools/.libs/tiffcrop -F both ../libtiff/test/images/miniswhite-1c-1b.tiff o-tiffcrop-doubleflip-miniswhite-1c-1b.tiff ==11173== Memcheck, a memory error detector

==11173== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.

==11173== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info

==11173== Command: tools/.libs/tiffcrop -F both ../libtiff/test/images/miniswhite-1c-1b.tiff o-tiffcrop-doubleflip-miniswhite-1c-1b.tiff

==11173==
==11173== Invalid read of size 1

==11173==    at 0x4164FF: reverseSamples16bits (tiffcrop.c:8600)
==11173==    by 0x4171C2: mirrorImage (tiffcrop.c:8935)
==11173==    by 0x413C8B: createCroppedImage (tiffcrop.c:7536)
==11173==    by 0x405BF8: main (tiffcrop.c:2302)
==11173==  Address 0x5f4445c is 0 bytes after a block of size 3,020 alloc'd
==11173==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==11173==    by 0x4E8D06F: _TIFFmalloc (tif_unix.c:263)
==11173==    by 0x410547: loadImage (tiffcrop.c:6004)
==11173==    by 0x405ADB: main (tiffcrop.c:2272)

==11173==

And exact same trace with the FAIL: tiffcro