2013.08.31 11:39 "[Tiff] Slightly corrupted tiff image causes libtiff to crash with double free or corruption", by Konstantin

2013.09.03 09:43 "Re: [Tiff] Slightly corrupted tiff image causes libtiff to crash with double free or corruption", by Joris Van Damme

I suspect that this thread is going off-topic for the Tiff mailing list, so my apologies to the list readers, but to not leave any loose-ends for those who may read this later...

That is appreciated. And I don't think it's off-topic. We've seen similar trouble before in other contexts, so at least part of the strategy in dealing with this can and should be generalized.

If the image data in the JBIG data actually exceeded these values, then the sender's system erred in the produced BIH marker. As HylaFAX deliberately attempts to preserve the data as-sent by the sender in this case I do not believe that this should be considered a HylaFAX bug. The bug would be with the sender. If libtiff crashes on processing such a tif, then that's a bug in libtiff and not with HylaFAX.

This situation may arise with all compression formats that have their own headers and stuff. For example, JPEG compression inside TIFF, presents the same problem where the actual JPEG stream logically and explicitly contains dimension information that may contradict the TIFF IFD information.

Even if in this case in particular, it seems you have a contradiction between the logically and explicitly contained dimension information, the situation remains essentially the same.

It is my opinion that the TIFF IFD tag values should be taken as the actual dimensions. Because, otherwise, we end up in a situation where we'll be required to decode (or at least partially scan) compressed streams in order to auto-correct the tag values, and that is unsustainable. It would also be impossible for those decoders who don't know the particular compression scheme or don't support it and maybe are interested in image dimensions only. Meaning, end-user image dimension values would actually depend on support for a particular compression scheme.

So, in my opinion, it may seem trivial but it is important to clearly agree tag value data takes precedence over information logically and/or explicitly contained in the compressed strip or tile data.

It seems logical to not merely error-out when decompressing the images stream when there is said contradiction (though certainly throwing an error is a lot better then crashing which indeed obviously should be regarded a dangerous bug), but padding/cropping the decompressed image stream instead, in order to fit those TIFF image dimension tag values.

I do realize this remark doesn't actually contribute, nor does it contradict anything that has been said in this thread. And it may seems trivial. But I feel it is important to establish this.

Best regards,

Joris Van Damme

info@awaresystems.be