AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
December 2018

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2018.12.08 20:43 "Zlib inflate recovery action required?", by Bob Friesenhahn
2018.12.08 21:14 "Re: Zlib inflate recovery action required?", by Bob Friesenhahn
2018.12.08 21:22 "Re: Zlib inflate recovery action required?", by Olivier Paquet
2018.12.08 21:29 "Re: Zlib inflate recovery action required?", by Even Rouault
2018.12.08 21:42 "Re: Zlib inflate recovery action required?", by Bob Friesenhahn
2018.12.08 22:03 "Re: Zlib inflate recovery action required?", by Toby Thain

2018.12.08 21:29 "Re: 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
_______________________________________________
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff