Re: [PATCH] vfprintf stack overflow [BZ #16617]

[Florian Weimer <fweimer at redhat dot com>]

On 12/05/2014 06:01 PM, 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).

On 32-bit systems, the largest possible size is 3221225472, which 
corresponds to 67108864 format specifiers.  At four characters per 
format specifier, this means that roughly 80% of the 32-bit address 
space need to be allocated before the overflow occurs, in two fairly 
large chunks.  It seems rather unlikely this is possible (it certainly 
requires a 32-bit kernel).  In my test, it's not.

I need to add the NULL check anyway, as OndÅej pointed, so I'll resubmit 
with both changes included.  But I think that both changes are just 
hardening, so no new CVE ID is needed.

--
Florian Weimer / Red Hat Product Security