[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE Request: libtiff: Heap-buffer overflow when processing a TIFF image with Pixa
From:       Tom Lane <tgl () redhat ! com>
Date:       2012-09-26 16:43:19
Message-ID: 27084.1348677799 () sss ! pgh ! pa ! us
[Download RAW message or body]

Huzaifa Sidhpurwala <huzaifas@redhat.com> 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
[prev in list] [next in list] [prev in thread] [next in thread]