2020.08.28 07:22 "[Tiff] Valgrind reports invalid read when using uint8 RichTiffIPTC tag values in TIFFSetField()", by Agnish Dutta

2020.08.31 14:27 "Re: [Tiff] Fwd: Valgrind reports invalid read when using uint8 RichTiffIPTC tag values in TIFFSetField()", by Bob Friesenhahn

We noticed some erroneous behavior when trying to use this library to set the “RichTiffIPTC tag. From the following line in the ‘tif_dirinfo.c’ file,

{ TIFFTAG_RICHTIFFIPTC, -3, -3, TIFF_LONG, 0, TIFF_SETGET_C32_UINT32, TIFF_SETGET_UNDEFINED, FIELD_CUSTOM, 0, 1, "RichTIFFIPTC", NULL }

It looks like RichTiffIPTC tag values are expected to be in ‘long’. As a result when uint8 data is passed to the “TIFFSetField()” function, the data bytes aren’t set in the right order and the values get garbled up.

From notes that I put into GraphicsMagick code, when the tag is TIFFTAG_RICHTIFFIPTC then the length specifies the number of 32-bit words.

We were wondering if this is a known issue or a workaround to fix these invalid read? Are we not supposed to use BYTE/uint8 values to write ‘RichTIFFIPTC’ tag in TIFF files. If not, what is the recommended way?

If you must use this tag, then I suggest that its content should be treated as an array of 32-bit words. The data should be entirely initialized in order to avoid valgrind complaints. Regardless of how you handle the data, the allocation size should be rounded up to be 32-bit aligned and the size passed to libtiff should be the number of 32-bit words that the data may be represented by.

This tag and the "IPTC" profile/chunk that it represents was entirely disowned by the IPTC organization many (perhaps 20) years ago. Regardless, it continues to be used.

Bob

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