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: Rich Felker <dalias at aerifal dot cx>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 20 Oct 2013 12:35:31 +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>
On 10/20/2013 04:47 AM, Rich Felker wrote:
On Fri, Oct 18, 2013 at 01:30:07PM +0200, Florian Weimer wrote:
+#define _FORTIFY_H 1
+/* Check that USER length does not exceed the COMPILER length (which
+ should have been obtained through __builtin_object_size), and that
+ USER does not exceed INT_MAX minus some reserve.
+ Technically, a caller to functions like snprintf could specify
+ (size_t)-1 as the buffer length to get the behavior of sprintf
+ (without target buffer length checking), but we do not support this
+ use in fortify mode. */
+static inline void
+__check_buffer_length_int_max (size_t user, size_t compiler)
+ if (__builtin_expect (compiler < user || user >= INT_MAX - 1024, 0))
+ __chk_fail ();
POSIX already requires an error from snprintf if the size passed to
snprintf is greater than INT_MAX, although this possibly conflicts
with the requirements of ISO C (this needs to be addressed by the ISO
C committee). If you believe there is any value in rejecting sizes
above INT_MAX-1024, I think you need a strong argument for doing so.
See the patch from Exim I posted.
Note that this is for fortify mode only. Both ISO C and POSIX require
that you end up with sprintf behavior when you specify (size_t)-1 as the
buffer length. (Neither standard requires that the size argument is the
length of the buffer.) The fortify implementation already aborts in
that case (even if the result would fit into the supplied buffer), so my
proposal is less radical than you might think.
I'm open to tweaking the magic number, perhaps to ((size_t)-1)/2 - 1024
or something like that. But I do think that check makes sense, as
exemplified by Exim.
Florian Weimer / Red Hat Product Security Team