Why electric fence/Valgrind is unable to catch this buffer-overflow issue?

Question

I have created a buggy program - buggy.c - this is a buffer-overflow scenario for buffer t. You can see that I am writing more than 5 indexes. It works fine. It never throws me an error. I was wondering, why is it like that? I tried even Valgrind, this also couldn't find this issue. Can you tell me please what is the issue here?

void buffer_overflow(void)
    {
      int t[5];
      int i = 0;

      for(i = 0; i<=7; i++)
      {
        t[i] = i;  

      }


      /** this will cause buffer overflow **/   
      printf("Memory_overflow_completed\r\n");

    }


    int main(int argc, char **argv)
    {

      buffer_overflow();

      return 0; 
    }

    $gcc -g buggy.c -o buggy.out -lefence

$./buggy.out

However, I don't get any crash. There is no effect of electric fence here. What am I missing? I saw the similar question posted here gcc with electric fence library does not take effect, but there seems to be no answer yet. I am running this example on FC19. Does anyone has an answer to it? Even valgrind fails to detect the issue? Is there any other tool to detect these issues?

Based on the further comments, I revised the buffer-overflow function to get detected by Electric Fence. However,Electric Fence cannot detect the issue. Here is the modified function.

void buffer_overflow(void)
{

  #if 0
  int t[5];
  int i = 0;

  for(i = 0; i<=7; i++)
  {
    t[i] = i;  

  }
  #endif

  char *t = malloc(sizeof(char)*7);
  strcpy(t,"SHREYAS_JOSHI");


  /** this will cause buffer overflow **/   
  printf("Memory_overflow_completed\r\n");
  free(t);

}

[joshis1@localhost blogs-tune2wizard]$ gcc -g buggy.c  -o buggy.out -lefence

[joshis1@localhost blogs-tune2wizard]$ ./buggy.out 

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Memory_overflow_completed

There is no error detected by Electric Fence, but Valgrind atleast showed it.

Answer 1

Valgrind is limited by having only the binary available. If you don't mind some instrumentation being inserted in your code (by compiler), you can try address sanitizer. It poisons memory around allocated areas (even on stack) and then checks every read/write, so it has higher chance to catch these problems.

It's integrated in current gcc (4.8+) and clang (3.2+) Just compile your code like:

gcc -g buggy.c  -o buggy.out -fsanitize=address

Upon execution, it prints something like:

==26247== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff9fa0be54 at pc 0x4008df bp 0x7fff9fa0be00 sp 0x7fff9fa0bdf8
WRITE of size 4 at 0x7fff9fa0be54 thread T0

and a stack trace.

Chandler Carruth talked about it in this talk at GN13

Note: It is supported even in clang 3.1, but the switch is called -faddress-sanitizer instead of -fsanitize=address.

Answer 2

Running valgrind --tool=exp-sgcheck ./buggy.out and it should be able to detect that you have buffer overrun within the local variable t[5]

Answer 3

Valgrind and EF detect errors in dynamically-allocated memory. Your array is not dynamically-allocated.

Answer 4

Citing from valgrind quick start guide: "For example, it can't detect out-of-range reads or writes to arrays that are allocated statically or on the stack."

Answer 5

To detect out-of-bounds accesses in statically allocated memory (i.e. on the stack), you can use a static code analysis tool.

One that we've just begun to use at work is Klocwork

As mentioned on the Valgrind wiki page (under limitations of memcheck), it can't detect out of bound accesses on statically allocated memory. Quoting from the wiki:

The experimental valgrind tool exp-sgcheck has been written to address this limitation in Memcheck. It will detect array overrun errors provided the first access to an array is within the array bounds.