Re: gcc 4.2 optimizations and integer overflow checks

[Richard Guenther <rguenther () suse de>]

On Mon, 21 Apr 2008, Solar Designer wrote:

> I'm sorry for failing to find time to comment on this earlier.
>
> On Fri, Apr 18, 2008 at 01:18:32PM +0200, Marcus Meissner wrote:
> > On Thu, Apr 10, 2008 at 02:31:13PM -0400, Steven M. Christey wrote:
> > > My immediate suspicion is that they're not the same, based solely on
> > > affected versions - CVE-2008-1685 has a specific affected version range
> > > because it changed behaviors in 4.2.0.  Maybe that change came out of
> > > followup analysis stemming from CVE-2006-1902.
> > >
> > > But, I'm not completely sure.  Solar?
> >
> > They are mostly unrelated, one is about signed integers, while the
> > new one is "pointer + offset" related.
>
> Yes, I am aware of these two gcc non-bugs - one is that the behavior on
> signed integer overflow is undefined, the other is that pointer
> arithmetic is only defined within the object (and one element beyond its
> end).  So this would be two CVEs, if CVEs are to be assigned for things
> like that at all (are they for common application bugs? or for the gcc
> non-bugs?)
>
> However, the current descriptions and references for CVE-2006-1902 and
> CVE-2008-1685 are very confusing.  Neither appears to be for signed
> integer overflows being undefined.  By the way, this issue was discussed
> on mailing lists in 2002, so I presume that gcc started doing that kind
> of optimizations at about that time.  In fact, I've been fixing some of
> my own older code to use unsigned arithmetic or to pre-check (rather
> than post-check) for potential integer overflows at about that time.
>
> Both CVE-2006-1902 and CVE-2008-1685 refer to gcc bug 26763, which deals
> with the pointer arithmetic issue.  It appears that gcc developers
> decided to not have gcc take full advantage of pointer arithmetic
> outside of the object being undefined, thus fixing the bug on 2006-04-05.
> But I could be wrong here - maybe the fix is for an actual gcc bug only.
> The most straightforward and reliable way to find this out is to ask one
> of the gcc developers who worked on this bug (I'd ask Richard Guenther).

The referenced bug (26763) was about not correctly interpreting an
offset to a pointer as a signed value, which basically means that
GCC before that bug was fixed optimized p + -1 > p to true, independent
of whether the offsetting wraps or does not wrap.  The bug was fixed
not by interpreting the offset as signed but to restrict optimizing
of a certain class of pointer comparisons to == and != comparisons
which are not affected by the signedness problem.

The optimization was properly re-introduced with reasoning as in
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00452.html
(unfortunately that IRC session mentioned is not available)

Later this folding code was superseeded with what we have now (not
re-introducing this bug as you can see from the still working testcases
that got added at that time), which correctly interprets offsets as
signed.  The old code fixed code was finally removed with

2007-10-15  Richard Guenther  <rguenther () suse de>

        * fold-const.c (extract_array_ref): Remove.
        (fold_comparison): Handle POINTER_PLUS_EXPR with the
        generic address expression comparison folding.  Remove
        the folding that used extract_array_ref.

for GCC 4.3.

> Finally, CVE-2008-1685 refers to "gcc 4.2.0 through 4.3.0", which means
> that it can't be for the non-bug (or actual bug?) that got fixed in 2006.
> Yet I think that the reference to gcc bug 26763 is somewhat relevant,
> because both CERT VU#162289 and comments on that bug mention the
> wraparound case.  My limited understanding is that the fix that got
> committed on 2006-04-05 would deal with the wraparound case as well.
> However, perhaps - I am just guessing here - the same issue (a non-bug)
> got re-introduced with another change to gcc later, and we do not
> currently have a reference for that in the CVE entries.

As explained above it was a real bug and not related to pointer
overflow (though the testcases look similar).

> I am really not into gcc internals, so it doesn't make sense for me to
> continue to speculate on this.  Please ask the people who actually know,
> such as Richard.

A wise suggestion.  We GCC folks hope there will be no repetition of
such bad and wrong CERT reports like 162289 which - despite repeated
request - got not updated to reflect reality and as such still badly
damages both CERT and GCC reputation.

Richard.

-- 
Richard Guenther <rguenther () suse de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex