Since buffer overflows always let an evil hacker write outside the buffer and overwrite the return pointer to a shellcode the evil hacker can place, does it mean that successful exploitation of a stack buffer overflow always means the ability to invoke a shell if done the right way? At least in theory, if you assume that DEP and ASLR is not in place.

  • 9
    Don't forget that the attacker might not want arbitrary code to run; they might merely want to choose which existing code runs, or even not run. The ability to choosing to, say, not execute a security check when one is warranted is an attack vector. Nov 27, 2019 at 20:28

3 Answers 3


No, a buffer overflow might:

  • Be against a buffer on the heap not the stack. This might still lead to code execution but will be much more complicated to exploit.
  • Be limited in size, so not able to overwrite return pointers. (e.g. be able to only write 1 byte beyond the buffer)
  • Be restricted in which bytes can be written, preventing suitable pointers to be written.
  • Overwrite stack cookies, which are detected before the return address is used. Unless the cookie is leaked, the exploit would crash the process the vast majority of the time, rather than leading to code execution.
  • Be on a stack growing upwards, so not be able to overwrite return addresses. An exploit might still be able to overwrite other local variables, or the buffer might be passed to another function, but wouldn't lead to code execution as reliably as downwards stacks.

Some of these might still lead to code execution, but other instances might be impossible to exploit.

However once you've found where a buffer overflow is happening it's usually much easier to fix it, than to prove it can't be exploited.

  • 19
    It's worth noting that all these properties might result in a buffer overflow that's not exploitable. There have been many remote code executions based on heap overflows, there are techniques that bypass stack canaries, bad bytes and size limitations, an overflow on an upwards-growing stack might be able to overwrite local variables in a manner that somehow enables RCE, etc. So a buffer overflow should be viewed as a potential vulnerability even if it seems not exploitable at the first glance.
    – Peteris
    Nov 27, 2019 at 0:50
  • 30
    chicken is a common vector for food poisoning, but not every chicken causes food poisoning.
    – coteyr
    Nov 27, 2019 at 3:31
  • 2
    "Be limited in size, so not able to overwrite return pointers". Ah you'd think you couldn't do anything with that, but alas that's not true. I remember a fascinating linux code execution exploit where only a single byte on the stack could be overwritten at a time.
    – Voo
    Nov 27, 2019 at 13:59
  • 4
    Is every chicken exploitable if one wishes to food-poison someone?
    – Beanluc
    Nov 27, 2019 at 17:08
  • 3
    Writing even a single NUL byte off the end of a buffer can still be quite exploitable and is a very common off-by-one error when dealing with strings; see googleprojectzero.blogspot.com/2014/08/… for example. While, yes, not all buffer overflows are exploitable, attackers can be remarkably clever.
    – nneonneo
    Nov 27, 2019 at 20:51

Douglas gives a correct answer. Not all buffer overflows give code execution. However, I felt it was missing a very important caution.

Even if a buffer overflow does not allow arbitrary code execution, that does not mean that it is safe.

A write buffer overflow lets you write to data that you are not supposed to. That data being a function address is just a special case. For example, suppose I have a user struct that has fields for name and privilege. It is easy to imagine how setting my name to "JosiahhasaverylongnameAdmin" could exploit a serious vulnerability, without any arbitrary code execution.

For another real world example, if you remember Heartbleed, that is a buffer overflow. It is just a read overflow rather than a write overflow. No chance of a code execution there, but a devastating breach of confidentiality even so.


The simple answer is no, not all buffer overflows are guaranteed to lead to code execution. The overflow could be too small to overwrite pointers/values needed, unable to control the overflowing part to overwrite things, or maybe too big which could kill stack cookies/canaries, etc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .