2013.09.01 17:16 "Re: [Tiff] Slightly corrupted tiff image causes libtiff to crash with double free or corruption", by Steve Underwood

Hi,

The results can be a little erratic when you overflow a buffer, so don't expect my results to be exactly the same as your. The actual problem is, as I said, the image lengths in the TIFF tags does not match the image length in the image data. Bad things will happen if that in cases, although libtiff really ought to pick up conditions like this and handle them in a benign way. For example, jbigkit has facilities to limit the size of a decoded image. If libtiff limited the image to the size shown in the TIFF tags you should not see crashes.

I believe HylaFAX extracts the size of the image from the JBIG header, and uses this to set the TIFF tags. It doesn't actually decode the image. If I am right about this, something must be wrong in the way the length is extracted from the image and used to set the tags. This is looking like a HylaFAX problem.

Regards,
Steve

On 09/02/2013 12:54 AM, Konstantin wrote:

interesting results but mine differ a little. So on my system (Gentoo, 32 Bit, tiff-4.0.3-r2)

tiffcp page2.tif test.tif

produces a "working" file, I had no issues on the file(s) processed by tiffcp. This way I managed to repair the fax file using tiffsplit..., tiffcp pageX.tif newpageX.tif, tiffcp newpage*.tif repairedfax.tif.

As I said, any program using libtiff I tried (including xv) was crashing with page2.tif but only if processed after some regular file - except for okular, which crashes directly. As the error is a glibc double free error it doesn't seem to me to be an access behind the allocated memory buffer but as I don't know how glibc detects this (a free() on NULL or unassigned address I assume) my assumption may be wrong.

Have you tried viewing the pages with xv? You may try

xv page2.tif page1.tif

where you will be able to see both images (space) but when you return (backspace) to page2.tif xv will crash. I'm very curious what is not initialized correctly after processing a regular image so the bad one causes a crash.

If you think it's also a libtiff fault, should I post a bug for this or wait for your final findings?

Regards,
Konstantin

Steve Underwood schrieb am 01.09.2013 17:59:

> Hi Konstantin,
>
> I did some more work on this. Your problem is the TIFF tags in

> page2.tif say the image is 1149 pixels long, while the JBIG data says > it is 1152 pixels long. If I patch the tags to say 1152, the image

> seems to work OK. So, it looks like the wrong length is being set when > HylaFAX writes the file. Things like okular are crashing because they

> allocate enough space for an 1149 row image, but the decoder produces > 1152 rows, and overflows the buffer. If you try to use tiffcp to copy

> page2.tif, it tries to recode the image, and makes a mess. tiffcp also > produces JBIG files which are not T.85 compatible, which is why my

> software was crashing when I forced your data into it. I now do more > thorough checking for invalid data, and no longer crash.

> On 09/01/2013 02:56 PM, Steve Underwood wrote:
>> Hi Konstantin,
>>
>> I am using the libtiff-4.0.3 that is in Fedora 19
>>

>> It looks like both libtiff and jbigkit are at fault. It seems libtiff >> is clipping off the last bit of the image when it stores it. If you try

>>
>> tiffcp page2.tif test.tif
>>

>> page2.tif has a compressed image 23296 bytes long, but test.tif has a >> compressed image 23270 bytes long. I can process the one in

>> page2.tif, but I can't process the one in test.tif.

>>
>> So, something seems wrong in libtiff, but jbigkit is also at fault

>> here. It really shouldn't be crashing. For reference it seems my own >> T.85 compression/decompression also has issues here, which I need to

>> look into.
>>
>> Regards,
>> Steve
>>
>>
>> On 09/01/2013 02:59 AM, Konstantin wrote:
>>> Hi Steve,
>>>

>>> thank you for your reply. I was wondering about JBIG myself but as even >>> tiffcp without recompression parameters failed, I was thinking about

>>> libtiff. Please see the attached files. page1.tif is a regular page and >>> page2.tif is the broken one. They were received on the same

>>> transmission. If you view/process page2 alone it usually works (except >>> using KDE's okular). Let's see what you code does ;-).

>>>
>>> Regards,
>>> Konstantin
>>>
>>> Steve Underwood schrieb am 31.08.2013 13:57:

Its more likely your problem is in jbigkit rather than libtiff, so it might be worth looking for help from its author.

I would be interested in seeing some of your bad files. I have my own implementation of T.85 (the subset of JBIG used for FAX), and I use libtiff to read and write these images as the T85 compression type defined in the TIFF-FX spec. If some FAX systems send you bad images I would like to see how my code reacts to them.

On 08/31/2013 07:39 PM, Konstantin wrote:

>>>> on a tiff image received per fax one of the pages has some strange corruption which causes libtiff (and any program using it) to

>>>>> crash in a

strange way. If only the corrupted page is processed or it is

>>>>> processed

first, there is no problem. But if more pages are processed and the corrupted one is not the first one, an error like the following

>>>>> appears:

>>>> *** glibc detected *** tiffcp: double free or corruption (!prev):

>>>>> 0x095b4eb8 ***

======= Backtrace: ========= /lib/libc.so.6[0x444306e1] /usr/lib/libtiff.so.5(_TIFFfree+0x1a)[0x47cc4d40]

tiffcp[0x804af7a]
tiffcp[0x804a33a]
/lib/libc.so.6(__libc_start_main+0xe6)[0x443da572]
tiffcp[0x804a415]

>>>>>>

>>> It seems to me as there is some data structure that is not

>>>>> initialized

correctly between the iterations when processing the pages.

>>>> If anyone is interested in finding this bug please let me know so

>>>>> I can

send you a good and the bad page (24kB each). Otherwise I will

>>>>> discard

the bad images in a while. Here the tiffinfo output:

>>>> TIFF Directory at offset 0x5a08 (23048)
    Subfile Type: multi-page document (2 = 0x2)
    Image Width: 1728 Image Length: 1152
    Resolution: 200, 100 pixels/inch
    Bits/Sample: 1
    Compression Scheme: ISO JBIG
    Photometric Interpretation: min-is-white
    FillOrder: lsb-to-msb
    Orientation: row 0 top, col 0 lhs
    Samples/Pixel: 1
    Rows/Strip: (infinite)
    Planar Configuration: single image plane

  ImageDescription: +49 7625 13237162
  Make: VER. 1.26 VOM 18.07.97
  Model: 282
  Software: HylaFAX (tm) Version 6.0.3
  DateTime: 2013:08:27 13:21:55
  HostComputer: router
  FaxRecvParams: 2170920
  FaxRecvTime: 18
  FaxDcs: 00 44 1F 21 01 11 01 01 01 02