A payroll service accepts a department name up to 64 characters. A tester submits 2,000 characters, the service crashes, and a core dump shows the program trying to execute part of the input as instructions. A field meant for a word became a way to take over the process.
That is a buffer overflow, and it sits beside privilege escalation on the CompTIA Security+ SY0-801 exam under objective 2.5, which asks you to analyze indicators of malicious activity. The two belong together because they are often two steps of one intrusion: an attacker exploits a flaw like an overflow to run code, then escalates to gain the access they actually want. This lesson explains how overflows corrupt memory at a concept level, how the operating system and modern languages fight back, and how attackers move from a low-privilege foothold to full control, vertically and horizontally.
A buffer overflow writes past the memory set aside for input
A buffer is a block of memory a program reserves to hold data, such as 64 bytes for a name. A buffer overflow happens when the program writes more data into that block than it can hold, and the extra data spills into adjacent memory. The root cause is code that copies input without checking its length, a mistake possible in languages like C and C++ that let the programmer manage memory directly and do not check bounds automatically.
At first the overflow just corrupts whatever sat next to the buffer, which usually crashes the program. That crash is the first indicator: a service that reliably dies when fed an overly long input is signaling an overflow bug. The danger is that an attacker who understands the memory layout can choose exactly what to overwrite. Instead of random corruption, they place their own data in the right spot and redirect the program to code of their choosing, which runs with the privileges of the vulnerable process.
For the exam you need the concept, not the exploit. The marker of a buffer overflow in a scenario is input that exceeds a fixed size and either crashes a program or leads to arbitrary code execution. You do not need to write shellcode or calculate offsets.
Stack and heap overflows corrupt different regions of memory
Programs use two main regions of memory while they run, and an overflow in each behaves differently. You should know the distinction at a high level.
The stack holds data for the function currently running: its local variables and the return address, which is where execution jumps back to when the function finishes. A stack buffer overflow can overwrite that return address. If the attacker controls the new value, they control where the program goes next, which is the classic route to running their code. Because the stack's layout is predictable, stack overflows were the original and most-studied form.
The heap is the region used for memory the program requests while running, such as objects whose size isn't known in advance. A heap overflow overwrites other data structures in that region, including pointers the program later follows. Heap overflows are generally harder to exploit than stack overflows because the layout is less predictable, but they are still dangerous. A related bug, the use-after-free, follows a pointer to heap memory that was already released, and an attacker who controls what now sits there can steer the program.
The exam does not require deep internals here. Know that the stack and the heap are two memory regions, that an overflow in either can let an attacker influence what the program does, and that both come from the same cause: writing more data than the allocated space can hold.