2

Example code:

int main ()
{
  char b[] = {"abcd"};
  char *c = NULL;
  printf("\nsize: %d\n",sizeof(b));
  c = (char *)malloc(sizeof(char) * 3);
  memcpy(c,b,10);   // here invalid read and invalid write
  printf("\nb: %s\n",b);
  printf("\nc: %s\n",c);

  return 0;
}

See in code I have done some invalid reads and invalid writes, but this small program works fine and does not create a core dump.

But once in my big library, whenever I make 1 byte of invalid read or invalid write, it was always creating core dump.

Question:

Why do I sometimes get a core dump from an invalid read/write and sometimes do not get a core dump?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Jeegar Patel
  • 26,264
  • 51
  • 149
  • 222

3 Answers3

6

It entirely depends on what you're overwriting or dereferencing when you do an invalid read/write. Specifically, if you're overwriting some pointer that gets dereferenced for example, let's say, the most significant byte of one, you could end up having something get dereferenced to a completely different (and completely invalid) area of memory.

So, for example, if the stack were arranged such that memcpy past the end of c would overwrite part of b, when you attempt to call printf() with b as an argument, it tries to take that pointer and dereference it to print a string. Since it's no longer a valid pointer, that'll cause a segfault. But since things like stack arrangement are platform (and perhaps compiler?) dependent, you may not see the same behavior with similar examples in different programs.

Dan Fego
  • 13,644
  • 6
  • 48
  • 59
4

What you are trying to do is basically buffer overflow & in your code sample more specifically heap overflow. The reason you see the crash only at times depends on which memory area you are accessing & if or not you have permission to access/write it (which has been well explained by Dan Fego). I think the example provided by Dan Fego is more about stack overflow (correction welcome!). gcc has protection related to buffer overflow on the stack (stack smashing). You can see this (stack based overflow) in the following example: 

#include <stdio.h>
#include <string.h>

int main (void)
{
    char b[] = { "abcdefghijk"};
    char c [8];
    memcpy (c, b, sizeof c + 1);      // here invalid read and invalid write
    printf ("\nsize: %d\n", sizeof b); 
    printf ("\nc: %s\n", c); 
    return 0;
}

Sample output: 

$ ./a.out 

size: 12

c: abcdefghi���
*** stack smashing detected ***: ./a.out terminated

This protection can be disabled using -fno-stack-protector option in gcc.
Buffer overflow are one of major cause of security vulnerability. Unfortunately function like memcpy do not check for these kinds of problems, but there are ways to protect against these kinds of problems.
Hope this helps!

another.anon.coward
  • 11,087
  • 1
  • 32
  • 38
  • +1, you're right; the memory located at `c` is on the heap, while `b` is on the stack. So in this circumstance, you're overflowing the heap. Good catch. ;) – Dan Fego Dec 27 '11 at 07:11
0

you create a 3 char string c, but you copy on it 10 chars. it is an error.

it is called a bufferoverflow : you write in a memory that doesnot belong to you. so the behavior is undefined. it could be a crash, it could works fine or it could modify another variable you created.

so the goo thing to do is to allocate enough memory for c to contain the content of b : 

c = (char *)malloc(sizeof(char) * (sizeof(b)+1)); // +1 is for the '\0' char that ends every string in c.

2 - when you copy b in c dont forget to put the end of string char : '\0'. it is mandatory in the c standard. so printf("%s",c); knows where to string finish.

3 - you copied 10 chars from b to c but b containd only 5 chars (a,b,c,d and '\0'), so the behavior of memcpy is undefined (e.g. : memcpy can try to read memory that cant be read,...).

you can copy only the memory you own : the 5 chars of b.

4 - i think the good instruction for defining b is : char b="abcd"; or char b={'a','b','c','d',0};

Hicham
  • 983
  • 6
  • 17