This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] vfprintf stack overflow [BZ #16617]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Rich Felker <dalias at libc dot org>, <libc-alpha at sourceware dot org>
- Date: Fri, 5 Dec 2014 22:42:30 +0000
- Subject: Re: [PATCH] vfprintf stack overflow [BZ #16617]
- Authentication-results: sourceware.org; auth=none
- References: <5481E0BD dot 9000203 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1412051657030 dot 4077 at digraph dot polyomino dot org dot uk> <20141205202639 dot GU4574 at brightrain dot aerifal dot cx> <54822AFD dot 6030407 at cs dot ucla dot edu>
On Fri, 5 Dec 2014, Paul Eggert wrote:
> On 12/05/2014 12:26 PM, Rich Felker wrote:
> > If N is the size of an actual allocated object, 2*N should not be able
> > to overflow. If it can, it means you already have a situation where an
> > object is so large that legal pointer subtractions overflow ptrdiff_t
> No, because the array elements are of type struct printf_spec, which is
> several bytes in size. So even if the number of bytes in the array exceeds
> PTRDIFF_MAX by a factor of (say) eight, subtracting addresses of array
> elements won't overflow.
Such subtraction of pointers differing by more than SIZE_MAX / 2 bytes
does not actually work in GCC (it does a subtraction, which overflows,
then a division - and that approach is fine for all normal arguments).
I think malloc should in principle disallow allocations of more than
SIZE_MAX / 2 bytes, but right now it doesn't, and I suspect a change would
break compatibility for various existing applications that expect to do
> 2GB allocations on 32-bit systems.
--
Joseph S. Myers
joseph@codesourcery.com