2011.10.04 14:22 "[Tiff] TIFF tags which result in bogus address from TIFFGetField()", by Bob Friesenhahn

2011.10.04 14:22 "[Tiff] TIFF tags which result in bogus address from TIFFGetField()", by Bob Friesenhahn

There are a number of private or vendor-specific tag IDs for which libtiff seems to either immediately crash, or return a bogus address to the user.

The most recent report of this problem is with tag 32781. With this tag, the request

   char *text = NULL;
   TIFFGetField(tiff,32781,&text);

results in the address 0x08 being returned in 'text'. Usually low-address values like this are due to a null pointer to a struct being dereferenced to a member offset in that struct. However, platforms which imediately crash when a null pointer is dereferenced (e.g. Debian Linux on x86) end up crashing immediately within TIFFGetField().

Previously I encountered similar problems with tags 33423 and 36867.

Is anyone aware of the cause or solution for this issue?

Here is a valgrind report using the Debian-provided libtiff 3.8.2:

==8841== Invalid write of size 8

==8841==    at 0x5068689: ??? (in /usr/lib/libtiff.so.4.2.1)
==8841==    by 0x50689B7: TIFFGetField (in /usr/lib/libtiff.so.4.2.1)
==8841==    by 0x650059: ReadTIFFImage (tiff.c:1699)
==8841==    by 0x443E9C: ReadImage (constitute.c:8448)
==8841==    by 0x42B148: ConvertImageCommand (command.c:3882)
==8841==    by 0x4249EC: MagickCommand (command.c:8171)
==8841==    by 0x424BE4: GMCommand (command.c:16046)
==8841==    by 0x40CA36: main (gm.c:61)
==8841==  Address 0x3 is not stack'd, malloc'd or (recently) free'd

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/