< MEDIUM: https://raaki-88.medium.com/buffer-overflow-linux-process-stack-creation-and-i-d6f28b0239dc >
Process and what happens during process creation have been discussed in this post previously — https://medium.com/@raaki-88/linux-process-what-happens-under-the-hood-49e8bcf6173c
Now, let’s understand what is buffer overflow:
A buffer overflow is a type of software vulnerability that occurs when a program tries to store more data in a buffer (a temporary storage area) than it can hold. This can cause the program to overwrite adjacent memory locations, potentially leading to the execution of malicious code or the crashing of the program. Buffer overflow attacks are a common method used by hackers to gain unauthorized access to a system.
Generally, C and C++ languages are more vulnerable to Buffer Overflow while programming languages like Python and Go have implementations which protect stack.
I have written the program in Python but had to use underlying C functionality to achieve similarly.
#!/usr/bin/python3
import ctypes
import pdb
buffer = ctypes.create_string_buffer(8)
ctypes.memmove(buffer, b"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",1000)
print('end of the program')
This is a very simple implementation where we created a buffer which can hold 8 bytes of memory, next we will create a new object which moves from one block of the memory to another but with a newer size, which will create a segmentation fault here, where in ‘A’ string will be attempted with the size of 100 bytes.
How this translates to stack, let’s understand this by a debugger, I have used Kali Linux in this case but you can use any system.
┌──(kali㉿kali)-[~]
└─$ sudo edb --run buffer_overflow_script.py
- let’s kick off the program with EDB, make sure that script has full access rights else EDB will not be able to access the stack.

2. Next let’s run the program to see what happens next, we should see the program crash because the memory allocated has been over-written erasing the next pointer in the stack.

3. Lets observe more closely



We can clearly see that blocks of memory are over-written than the allocated space, making the pointers point to something else, a more in-depth assembly language can help us narrow down to the level of the pointer, but that is not the intention of the post.

I hope this clears up the process, stack-allocation and stack overflow scenarios.
-Rakesh