[PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.

[Florian Weimer]

On 09/05/2016 07:27 PM, Maxim Ostapenko wrote:
> Although fortify is good thing as it (and it's enabled by default on
> some major distros e.g. Ubuntu and Gentoo), people still complain about
> {A, M}San vs fortify interaction, see e.g.
> https://github.com/google/sanitizers/issues/689. One possible solution
> would be to extend {A, M}San to support foo_chk() functions, but this
> would increase the complexity of sanitizer tools with quite small benefit.

I'm not sure if there is a small benefit.  Based on Mark's feedback on 
valgrind's capabilities compared to source fortification, I ran an 
experiment.

Consider this example program:

#include <stdlib.h>
#include <string.h>

struct foo {
   int a;
   char b[4];
   void *c;
};

int
main (int argc, char **argv)
{
   struct foo *p = malloc (sizeof (*p));
   strcpy (p->b, argv[1]);
   asm volatile ("" ::: "memory");
   free (p);
}

Compiled with -D_FORTIFY_SOURCE=2, passing a four-character string yields:

$ ./a.out aaaa
*** buffer overflow detected ***: ./a.out terminated
[…]

But compiling with clang 3.8 and -fsanitize=address (without source 
fortification), I can pass a longer string before Address Sanitizer 
detects the overflow:

$ ./a.out aaaaaaaaaaa
$ ./a.out aaaaaaaaaaaa
=================================================================
==21921==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60200000f000 at pc 0x000000488d77 bp 0x7ffe8eb00d50 sp 0x7ffe8eb00500

Depending on the application, intra-object overflows can be quite 
relevant.  Is this perhaps a sufficient case for Address Sanitizer using 
this data as well?

Thanks,
Florian