Re: CVE Request: libtiff: Heap-buffer overflow when processing a TIFF image with PixarLog Compression

[Tom Lane <tgl () redhat com>]

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