Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Sep 2012 12:43:19 -0400
From: Tom Lane <>
To: Huzaifa Sidhpurwala <>
cc: Sebastian Krahmer <>,
Subject: Re: CVE Request: libtiff: Heap-buffer overflow when processing a TIFF image with PixarLog Compression

Huzaifa Sidhpurwala <> writes:
> On 09/26/2012 12:27 PM, Sebastian Krahmer wrote:
>> As well as the patch:
>> -	sp->tbuf = (uint16 *) _TIFFmalloc(tbuf_size);
>> +	sp->tbuf = (uint16 *) _TIFFmalloc(tbuf_size+sizeof(uint16)*sp->stride);
>> If there were sizeof(uint16)*sp->stride bytes missing before, this is really
>> more than just a few bytes. I checked that the mult cannot overflow,
>> as sp->stride seems to be uint16. However, I think the add can actually wrap,
>> (at least on ILP32) as tbuf_size can be 0xffffffff or so.
>> I think the patch is broken and just shifts the hole.
> It seems that sp->stride is at most td_samplesperpixel.

> Re-thinking about the patch, it does seem a bit broken now.
> Tom,
> Any inputs on this?

Yeah, I was wondering about the possibility of an overflow there too.
The amount being added is very small but in principle tbuf_size could be
just below the overflow threshold.  And I agree that it would be saner
to increase tbuf_size itself.  Having said all that, I still don't
understand why this buffer needs padding at all.

			regards, tom lane

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.