[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Sep 2012 12:43:19 -0400
From: Tom Lane <tgl@...hat.com>
To: Huzaifa Sidhpurwala <huzaifas@...hat.com>
cc: Sebastian Krahmer <krahmer@...e.de>, oss-security@...ts.openwall.com
Subject: Re: CVE Request: libtiff: Heap-buffer overflow when processing a TIFF image with PixarLog Compression
Huzaifa Sidhpurwala <huzaifas@...hat.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
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.
