This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #14771] Fortify tweak for snprintf et al.
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 21 Oct 2013 14:03:45 +0200
- Subject: Re: [PATCH][BZ #14771] Fortify tweak for snprintf et al.
- Authentication-results: sourceware.org; auth=none
- References: <52611BBF dot 7000500 at redhat dot com> <20131020024756 dot GH20515 at brightrain dot aerifal dot cx> <5263B1F3 dot 4040808 at redhat dot com> <20131020161449 dot GJ20515 at brightrain dot aerifal dot cx> <5264E67D dot 2060406 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310211152181 dot 23978 at digraph dot polyomino dot org dot uk>
On 10/21/2013 01:58 PM, Joseph S. Myers wrote:
On Mon, 21 Oct 2013, Florian Weimer wrote:
Hmm. There is no up-front check to return EOVERFLOW in glibc, and the GCC
folder doesn't know about it, either. :-( EOVERFLOW is apparently returned
only if the actually produced string is at least INT_MAX characters long (this
is the fprintf etc. behavior).
Apart from the Austin Group response not really engaging with the conflict
with a case that's fully defined in C99, I don't think there's anything
useful for GCC to know about regarding overflows on printf folding - GCC
can't handle strings longer than host INT_MAX (which in practice will be
the same as target INT_MAX for glibc targets) as it uses "int" to record
the length of a STRING_CST (in general, there are many places in GCC using
"int" to store sizes of target objects, host allocations, etc.).
It ignores the buffer length argument to snprintf during some parts of
folding. This means that simple test cases for EOVERFLOW checking do
not actually exercise the glibc implementation. Beyond that, it's
probably not an issue.
Florian Weimer / Red Hat Product Security Team