On 08/17/2012 09:15 PM, Gabriel Dos Reis wrote:
Hmm, I think it help a little bit if you could expand on where exactly
the danger the patch is trying to prevent is, and where what
does "unbound parameter" refer to or mean? (I don't know what
an unbound parameter is)
Sorry for being unclear. I haven't found good terminology yet.
I have seen some interfaces which behave very similar to gets(char *).
You pass in a buffer, and the called function writes data to it, and you
don't know how much will be written. A common pattern among those
functions was that they wrote to the argument buffer using strcpy or
sprintf. It seems to me that this always warrants a warning because any
false positive in the strcpy case could easily be optimized: if you
check the size of the target buffer before writing to it, you know the
length of the string you're going to write, so you can use memcpy
instead of strcpy. For sprintf, you'd just use snprintf directly,
removing the separate length check.
Function pointers come into play because these are supplied by the
caller. Ideally, we would flag any write to a pointer which does not
escape to the caller (because it is a pre-existing buffer), but this is
much more difficult to implement. (In C++ mode, the warning would be
disabled for non-constant reference-to-pointer-to-char parameters.)
Historically, there have been some APIs which had implied upper bounds
on buffer arguments (mainly PATH_MAX), but these have not fared well can
turn out very difficult to use correctly over time (readdir_r being an
example).
--
Florian Weimer / Red Hat Product Security Team
