Bug 441452 - (CVE-2008-1685) CVE-2008-1685 gcc: gcc-4.2 may optimize out certain length checks
CVE-2008-1685 gcc: gcc-4.2 may optimize out certain length checks
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2008-04-08 03:35 EDT by Tomas Hoger
Modified: 2014-08-20 16:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-01-13 15:59:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-04-08 03:35:00 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-1685 to the following vulnerability:

gcc 4.2.0 through 4.3.0 in GNU Compiler Collection, when casts are not used, considers the sum of a pointer and an int to be greater than or equal to the pointer, which might remove length testing code that was intended as a protection mechanism against integer overflow and buffer overflow attacks.

Comment 1 Tomas Hoger 2008-04-08 03:38:16 EDT
This issue currently does not affect any released version of Red Hat Enterprise
Linux or Fedora, as only gcc versions <4.2 are used.
Comment 2 Jakub Jelinek 2008-04-08 03:54:10 EDT
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

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.
Comment 3 Tomas Hoger 2008-04-09 02:45:18 EDT
Further discussion on gcc mailing related to this Cert advisory:

Comment 5 Vincent Danen 2011-01-13 15:59:00 EST
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.

Note You need to log in before you can comment on or make changes to this bug.