2018.11.10 19:39 "[Tiff] Libtiff 4.0.10 is now available", by Bob Friesenhahn

2018.12.08 21:29 "Re: [Tiff] Zlib inflate recovery action required?", by Even Rouault

On samedi 8 décembre 2018 14:43:41 CET Bob Friesenhahn wrote:

I have a TIFF pixar log compressed file for which zlib is reporting Z_DATA_ERROR from inflate() in tif_pixarlog.c line 816. It attempts to use inflateSync() to re-sync the stream and try to carry on. This issue occurs a few times and is then is followed on by uninitialized data access errors in zlib.

Looking at the code in libtiff, I don't see anything suspicious in the way we use the zlib API regarding to this, so the uninitialized data access is likely in zlib itself (not necessarily a security issue, but still annoying when sanitizing code).

Side node: technically, we do use zlib in a unspecified way since we call inflate() with Z_PARTIAL_FLUSH and zlib.h only mentions Z_NO_FLUSH, Z_SYNC_FLUSH, Z_FINISH, Z_BLOCK or Z_TREES as valid values for inflate() (the actual implementation in zlib 1.2.3 only honoured Z_BLOCK and Z_FINISH specifically, 1.2.11 adds Z_TREES to that). So in practice that's not an issue, although from the doc Z_SYNC_FLUSH would seem to be the flag we want ("Z_SYNC_FLUSH requests that inflate() flush as much output as possible to the output buffer")

Is it the consensus of opinion that an attempt to recover from Z_DATA_ERROR is valuable?

Looking at the code, I don't think it is valuable for at least 2 reasons:

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com