> So, what is the solution ? > > First, change > > TIFFReadScanline(in, buf, row, s) < 0 > > in tools/tiffcp.c to > > TIFFReadScanline(in, buf, row, s) <= 0 > > It is important to understand that 0 is also an error code here. Otherwise, > change error handling in tif_lzw to return negative numbers.
After taking a fresh look at it, this turns out to be a non solution
because TIFFReadScanline (the function between LZWDecodeCompat and
DECLAREcpFunc) converts 0 return codes to -1s.
> Then, there's maybe something to fix in tif_lzw, but I'm not quite sure
> at the moment and I still have to check that.
So, obviously the solution is in tif_lzw. Because of the ignore option,
we must understand the process of exiting not only as returning, but
most importantly as preparing the decoder for being called again with
the same corrupted memory state and the same buggy codes.
If we don't do that the next decoder call will stumble across the
corrupted memory and crash.
There are two things we have to handle: First, make sure the next
decoder call detects that it was previously interrupted and that the
oldcodep is invalid, so we avoid the crash.
Then, we have to be able to skip the buggy error code, because otherwise
we are going to run into an endless loop and we do not want that either.
I suggest to fix both issues via an additional flag in the decoder base
state. This flag would indicate the position where an invalid code can
be found.
Whenever this flag is set, we would fast forward to the next CODE_CLEAR
after the invalid code (according to my understanding of LZW, the whole
set of information between the corrupted code and the next CODE_CLEAR
may be corrupted or risky / hard to recover).
Concerning the Wheezy version, I have inspected the diffs and it is
still pretty unclear to me why the issue isn't reproducible because the
affected code it present. I'm still working on it.
Cheers,
Hugo
--
Hugo Lefeuvre (hle) | www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
signature.asc
Description: PGP signature
