BugTraq
gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 17 2006 08:03PM
Felix von Leitner (felix-bugtraq fefe de) (6 replies)
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 18 2006 07:16PM
Florian Weimer (fw deneb enyo de)
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 18 2006 09:21AM
Gabor Gombas (gombasg sztaki hu)
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 18 2006 07:45AM
Alexander Klimov (alserkli inbox ru)
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 18 2006 12:15AM
Nate Eldredge (nge cs hmc edu)
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 17 2006 11:57PM
Michael Chamberlain (michael chamberlain net au)
Felix von Leitner wrote:
...
> Here is one of my functions:
>
> static inline int range_ptrinbuf(const void* buf,unsigned long len,const void* ptr) {
> register const char* c=(const char*)buf; /* no pointer arithmetic on void* */
> return (c && c+len>c && (const char*)ptr-c<len);
> }
>
> Of course, when developing security critical code like this, you also
> write a good test suite for it, that exercises all the cases. Here is
> part of my test suite:
>
> assert(range_ptrinbuf(buf,(unsigned long)-1,buf+1)==0);
>
> Imagine my surprise when this assertion failed. I had compiled the
> code with gcc 4.1 and compiled it without optimizing (I mention this
> because for most gcc bugs, a workaround is disabling the optimizer).
>
The above function and call is invalid C - there is no allowance for
pointer wrap-around in the C language. Once the function call is
inlined, the "c+len>c" condition is effectively "c+[large positive
constant]>c", which (excluding wrap-around) must always be true. As
wrap-around can't occur in a valid program, GCC is performing a valid
optimisation.
> gcc 3 compiles this code correctly. I tested this on x86 and amd64.
> I mention this here because "c+len>c" is the code with which you would
> typically check for integer overflows, which is a check that for example
> an IP stack would do, or Samba. So, if you compiled your kernel with
> gcc 4.1, or your Samba, or some other packet handling code in a security
> relevant context, you might want to recompile with gcc 3.
>

GCC 3 happens not to make the inference that I describe above, but I
would suggest that any such buggy code (relying on undefined C language
semantics) be fixed, as it is only more likely over time that GCC (and
other compilers) will improve their ability to make inferences based
upon valid language semantics, resulting in "surprising" behaviour for
such code.

The only "bug" in GCC is that it is optimising this case when
optimisation is turned off.

Regards,
Michael.

[ reply ]
Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk Apr 17 2006 10:26PM
Forrest J. Cavalier III (mibsoft mibsoftware com)


 

Privacy Statement
Copyright 2010, SecurityFocus