In a compiled program (let's say C or C++, but I guess this question could extend to any non-VM-ish language with a call stack) - very often when you overflow your stack, you get a segmentation fault:
Stack overflow is [a] cause, segmentation fault is the result.
Is this always the case, though? Can a stack overflow result in other kinds of program/OS behavior?
I'm asking also about non-Linux, non-Windows OSes and non-X86 hardware. (Of course if you don't have hardware memory protection or OS support for it (e.g. MS-DOS) then there's no such thing as a segmentation fault; I'm asking about cases where you could get a segmentation fault but something else happens).
Note: Assume that other than the stack overflow, the program is valid and does not try to access arrays beyond their bounds, dereference invalid pointers, etc.
Stack overflowwhich causes the stack to overflow which results in a segmentation fault. Infinite recursion may not necessarily result in a stack overflow depending on the language, optimizations performed by the compiler and the exact structure of a code.
Yes, a stack overflow can cause a segmentation fault and core dump, but not always, it can also cause security breaches, and allow code to run that should not, it depends on how the software is designed and what precautions are taken.
Usually, when a stack overflow error occurs, the program crashes and can either freeze or close the program. Any unsaved data or work is lost. The stack overflow error is often caused by an infinite loop or the creation of variables larger than the size of the call stack.
The consequence of a stack overflow is that the program used, crashes as a result of incorrectly entered variables or because a return address contains no reachable target. In the case of an exploit, the attacker manages to overwrite the stack with their own code, thereby inserting this code in the return address.
Yes, even on a standard OS (Linux) and standard hardware (x86).
void f(void) { char arr[BIG_NUMBER]; arr[0] = 0; // stack overflow }
Note that on x86, the stack grows down, so we are assigning to the beginning of the array to trigger the overflow. The usual disclaimers apply... the exact behavior depends on more factors than are discussed in this answer, including the particulars of your C compiler.
If the BIG_NUMBER is just barely large enough to overflow, you will run into the stack guard and get a segmentation fault. That's what the stack guard is there for, and it can be as small as a single 4 KiB page (but no smaller, and this 4 KiB size is used prior to Linux 4.12) or it can be larger (1 MiB default on Linux 4.12, see mm: large stack guard gap), but it is always some particular size.
If BIG_NUMBER is large enough, the overflow can skip over the stack guard and land on some other piece of memory, potentially memory that is valid. This may result in your program behaving incorrectly but not crashing, which is basically the worst-case scenario: we want our programs to crash when they are incorrect rather than do something unintended.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With