Build fluency in the vocabulary of writing past a fixed-size buffer's end and overwriting adjacent memory.
0 / 5 completed
1 / 5
A teammate describes a bug where a program writes more data into a fixed-size memory buffer than it can hold, causing the excess bytes to overwrite adjacent memory, including potentially a function's return address. What is this vulnerability called?
A buffer overflow is exactly this: a program writes more data into a fixed-size memory buffer than it can hold, and the excess bytes spill over and overwrite adjacent memory, which can include critical values like a function's saved return address, letting an attacker potentially hijack control flow. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This write-past-the-buffer's-end approach is exactly why unchecked, fixed-size buffer writes remain a classic and dangerous vulnerability class.
2 / 5
During a security review, the team discovers a C function copies a user-supplied string into a fixed-size stack buffer using a function that never checks the input length against the buffer's size. Which risk does this represent?
This represents a buffer-overflow vulnerability, since an overly long input can write past the buffer's end and overwrite adjacent stack memory, including the return address. Copying the string with a bounded function that truncates input to the buffer's size would instead safely discard the excess bytes rather than writing them into adjacent memory. This unchecked-length-copy behavior is exactly why unbounded copy functions are flagged as dangerous once user-controlled input is involved.
3 / 5
In a code review, a dev notices a function copies a network-supplied packet payload into a fixed 64-byte stack buffer using an unbounded copy function, without first checking that the payload is 64 bytes or fewer. What does this represent?
This is a buffer-overflow risk, since a payload longer than 64 bytes would overwrite adjacent stack memory instead of being safely rejected or truncated. A cache eviction policy is an unrelated concept about discarded cache entries. This unbounded-copy-without-a-length-check pattern is exactly the kind of vulnerability a reviewer flags once the input source, such as the network, cannot be trusted to respect the buffer's size.
4 / 5
An incident report shows an attacker sent an oversized network packet that overwrote a function's saved return address on the stack, hijacking control flow, because the packet payload was copied into a fixed buffer with an unbounded copy function. What practice would prevent this?
Validating the payload length against the buffer's size before copying, or using a bounded copy function that truncates instead of overflowing, ensures excess bytes never overwrite adjacent stack memory. Continuing to copy the payload with the unbounded copy function regardless of how large an incoming network packet might be is exactly what let the attacker hijack control flow in this incident. This length-check-or-bounded-copy approach is the standard fix once unbounded copies from untrusted input are confirmed to be exploitable.
5 / 5
During a PR review, a teammate asks why the team insists on bounded copy functions and explicit length checks instead of the classic unbounded copy function that's already used throughout the older parts of the codebase. What is the reasoning?
Bounded copy functions trade a small amount of extra length-checking code for eliminating the possibility of writing past a buffer's end, while the classic unbounded copy function is simpler to call but overflows silently whenever input exceeds the buffer's size. This is exactly why bounded copy functions and explicit length checks are mandated for any buffer receiving untrusted input, while the older unbounded function remains a known liability that legacy code should be migrated away from.