2017.08.02 15:00 "[Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF

2017.08.03 15:23 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn

It seems best to block any negative size values from being passed into these functions in the first place. Libtiff is not in control of the I/O functions, so it is best to assure that they are not passed illegal values which might cause I/O implementations to do very bad things.

Not sure to understand what you mean here. Here are all call locations for SeekOK():

tif_dir.c: 2 times
tif_read.c: 4 times
tif_write.c: 1 time
tif_dirread.c: 3 times
tif_dirwrite.c: 9 times

Do you suggest to add an extra check for (off<0) before each call? If yes, I can prepare a patch.

Yes, I am suggesting that it is best to avoid passing a wrong request to the I/O functions (which might have been implemented by a library user or are implemented in a C library on any operating system libtiff may be compiled on) rather than dealing with a subsquent possible error return due to the wrong request. This approach assures consistent behavior. It can also produce a better quality (more appropriate) error message for the library user.

Also, is there any chance that TIFFSeekFile() could legitimately be called with off<0 and whence=SEEK_CUR? I mean, is there any reason to seek backward in a TIFF file? Looking at the code, the only calls to TIFFSeekFile(whence=SEEK_CUR) take (dircount*object_size) as an offset and should therefore always be positive, but I am not super-familiar with TIFF format(s).

I don't know what might happen in the future. We only know what libtiff does now. The seek operation used should be apparent at each call point.

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