Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Nov 2019 12:06:53 +0000
From: John Haxby <>
Subject: Re: Controversy and exploitability of gcc issue 30475
 |assert(int+100 > int)|

> On 8 Nov 2019, at 08:03, Georgi Guninski <> wrote:
> Controversy and exploitability of gcc issue 30475 |assert(int+100 > int)|
> There is heated discussion on gcc's bugzilla starting from 2007:
> and clang is also affected, depending on optimization flags.
> poc is the program at end.
> gcc with all optimization flags optimizes away |assert(a+100 > a)|
> even if there is no integer overflow, only signed overflow.
> clang fires the assertion with -O0, but also optimizes it away
> with -O3
> The formal verifier CBMC fires the assertion, which might of
> interest about formally verified programs.
> Signed integer arithmetic is commonly used even without integer
> overflows.
> Could this compiler issue be security problem?
> Any workarounds?

It's not really a compiler issue: the PoC is dependent on undefined behaviour and the compiler is free to do whatever it wants with undefined behaviour.  Many, many years ago I chatted with my then supervisor about having a compiler do interesting things with undefined behaviour for example, just replace that assert to print this to stdout:

	The Tao is forever undefined.
	Small though it is in the unformed state, it cannot be grasped.
	If kings and lords could harness it,
	The ten thousand things would come together
	And gentle rain fall.
	Men would need no more instruction and all things would take their course.
	Once the whole is divided, the parts need names.
	There are already enough names.
	One must know when to stop.
	Knowing when to stop averts trouble.
	Tao in the world is like a river flowing home to the sea.

Seriously, though, there are a lot of programs out there that *depend* on undefined behaviour being compiled in a particular way.   Sooner or later those programs mysteriously fail and that might lead to a security issue or just inexplicable behaviour.

In this particular case, the assert() will always trigger if the assert is on "a > INT_MAX-100" because that is well defined.   Does ubsan catch this issue?


> ===poc===
> #include <assert.h>
> int foo(int a) {
>  assert(a+100 > a);
>  printf("%d %d\n",a+100,a);
>  return a;
> }
> int main() {
>  foo(100);
>  foo(0x7fffffff);
> }
> =========
> CV:
> site:
> blog:

Download attachment "signature.asc" of type "application/pgp-signature" (269 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.