This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] vfprintf stack overflow [BZ #16617]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Jeff Law <law at redhat dot com>
- Date: Mon, 08 Dec 2014 11:55:19 +0100
- 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 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