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: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Fri, 5 Dec 2014 15:26:40 -0500
- 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>
On Fri, Dec 05, 2014 at 05:01:32PM +0000, Joseph Myers wrote:
> On Fri, 5 Dec 2014, Florian Weimer wrote:
>
> > This fell through the cracks. I took Jeff Law's patch (which we carry as a
> > local patch in Fedora and downstream), compressed the bug23-3.c test case, and
> > added Joseph's test case from the bug as bug23-4.c.
>
> What's your view of the other possible overflows there that Paul Eggert
> mentioned in <https://sourceware.org/ml/libc-alpha/2012-02/msg00102.html>?
> I think nspecs * sizeof (*specs) is always OK (that's the size of an
> object that's already been allocated), but 2 * nspecs_size might not be
> (if it can't overflow in practice, that's an accident to do with the
> size of struct printf_spec, the particular sequence of allocation sizes
> and how much memory it's actually possible to allocate on existing
> systems, rather than because the code is sensible to keep as-is without a
> check on that multiplication).
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,
which is a dangerous situation to begin with and should be fixed.
Rich