Bug 441452 (CVE-2008-1685)

This issue currently does not affect any released version of Red Hat Enterprise
Linux or Fedora, as only gcc versions <4.2 are used.

The #c1 comment is inaccurate, GCC is optimizing based on the assumption that
signed overflow doesn't happen and that pointer arithmetics is only defined
within the same object (pointer can point within an array (or immediately after
the last array element, in this case it can't be dereferenced though)).
It is just each new GCC release perhaps is more aggressive in doing so.
GCC 4.3 has newly -fno-strict-overflow option to trade performance for keeping
more broken code working, and -Wstrict-overflow{,=1,=2,=3,=4,=5} options to get
warnings about some cases where GCC optimizes based on the assumption that
signed overflow doesn't occur.  Ian Taylor yesterday proposed handling pointers
similarly:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00565.html

BTW, other compilers (icc, xlC) optimize based on this similarly, so it is
nothing specific to gcc.  Broken code triggering undefined behavior is a lottery
whether it will work as expected or not with any compiler version.

It would be good if setuid and other security exposed apps were test built with
-O2 -Wstrict-overflow=5 and analyzed.

Further discussion on gcc mailing related to this Cert advisory:

  http://gcc.gnu.org/ml/gcc/2008-04/msg00115.html

Looking at CERT's vendor statements (http://www.kb.cert.org/vuls/id/CRDY-7DWKWM):

	
GNU Compiler Collection Information for VU#162289
Date Notified:	
Date Updated:	2008-07-29
Statement Date:	
Status Summary:	Vulnerable
Vendor Statement
The behaviour of pointer overflow has now changed as of the following
(as yet unreleased) versions:

gcc 4.2.4
gcc 4.3.1
gcc 4.4.0

and all subsequent versions (4.2.x where x >= 4, 4.3.y where y >= 1,
4.z where z >= 4).

The optimization under discussion is for comparisons between P + V1
and P + V2, where P is the same pointer and V1 and V2 are variables of
some integer type.  The C/C++ language standards permit this to be
reduced to a comparison between V1 and V2.  However, if V1 or V2 are
such that the sum with P overflows, then the comparison of V1 and V2
will not yield the same result as actually computing P + V1 and P + V2
and comparing the sums.

The new behaviour as of the above releases is that this optimization
is performed by default at -O2 and above, including -Os.  It is not
performed by default at -O1 or (of course) -O0.  The optimization may
be enabled for -O1 with the -fstrict-overflow option.  The
optimization may be disabled for -O2 and above with the
-fno-strict-overflow option.

When the optimization is enabled, cases where it occurs may be
detected by using -Wstrict-overflow=N where N >= 3.  Note that using
this warning option is likely to yield a number of false positive
reports--cases where this or other overflow optimizations are being
applied, but where there is no actual problem.

Please see the gcc manual for more information about these options.


The above means this is not an issue in RHEL6 as it provides gcc-4.4.4.