Skip to content

Revised handling of TIFFTAG_INKNAMES and related TIFFTAG_NUMBEROFINKS value (fixes #149, #150, #152, #168, #250, #269, #398 and #456)

Su Laus requested to merge Su_Laus/libtiff:InkNames_NumberOfInks_handling_revised into master

In order to solve the buffer overflow issues related to TIFFTAG_INKNAMES and related TIFFTAG_NUMBEROFINKS value, a revised handling of those tags within LibTiff is proposed:

Behaviour for writing:

  • NumberOfInks MUST fit to the number of inks in the InkNames string.
  • NumberOfInks is automatically set when InkNames is set.
  • If NumberOfInks is different to the number of inks within InkNames string, that will be corrected and a warning is issued.
  • If NumberOfInks is not equal to SamplesPerPixel only a warning will be issued.

Behaviour for reading:

  • When reading InkNames from a TIFF file, the NumberOfInks will be set automatically to the number of inks in InkNames string.
  • If NumberOfInks is different to the number of inks within InkNames string, that will be corrected and a warning is issued.
  • If NumberOfInks is not equal to SamplesPerPixel only a warning will be issued.

This allows the safe use of the NumberOfInks value to read out the InkNames without buffer overflow.

This MR will close the following issues: #149 (closed), #150 (closed), #152 (closed), #168 (closed) (to be checked), #250 (closed), #269 (closed), #398 (closed) and #456 (closed). The MR closes #387 (closed), #463 (closed), #474 (closed) also.

It also fixes the old bug at http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of NumberOfInks = SPP was introduced, which is in my opinion not necessary and does not solve the general issue.

By the way, if this MR has been merged, the MR !145 (closed) can also simply be closed.

P.S.: The old function uint32_t checkInkNamesString() was replaced by the new function uint16_t countInkNamesString() which is not quite obvious when looking at the changes-log.

Edited by Su Laus

Merge request reports