- 2018.11.10 21:24 "Re: [Tiff] Libtiff 4.0.10 is now available", by
- 2018.11.15 23:37 "[Tiff] vcpkg port for 4.0.10", by Roger Leigh
- 2018.12.08 20:43 "[Tiff] Zlib inflate recovery action required?", 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:
- it would require the writing side to have emitted flush markers, and at known points (e.g end of line). On the write side, libtiff doesn't do that (that would degrade the compression rate)
- and on the read side, we don't do anything particularly clever when trying to recover, that is we put the new valid decoded values just after the ones before the corruption, which would completely mess the strip/tile/image. If we knew that the flush maskers would be at end of line, we could at least try to add padding for the missed values
- So yes, this recovery attempt has probably no practical value.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com