> 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 num
Hi,
> It looks like this buffer overflow is the consequence of an earlier buffer
> overflow in the GetNextCodeCompat macro:
Hum, that was not completely true. But I think I got it now.
The buggy sequence is:
1) Initialy oldcodep points to 0x63201890.
We get code 0x010c = 268, add it to t
It looks like this buffer overflow is the consequence of an earlier buffer
overflow in the GetNextCodeCompat macro:
> #define GetNextCodeCompat(sp, bp, code) { \
> nextdata |= (unsigned long) *(bp)++ << nextbits;\
> nextbits += 8;
Hi,
My current understanding of the problem (based on investigations on
latest master, but also valid for older versions):
The code_t string type is defined as a kind of chained list. Each entry
contains:
. a pointer to the next string entry
. a length field indicating the remaining length of th
Hi,
I have successfully reproduced this issue in latest upstream master
branch and Buster but couldn't reproduce it neither in Wheezy nor in
Jessie or Stretch.
I am going to take a closer look, try to prepare a patch and declare
Wheezy, Jessie and Stretch unaffected if appropriate.
Regards,
Hug
