CWE-121: Stack-based Buffer Overflow

When input exceeds the capacity of a stack-allocated buffer, it can overwrite adjacent data in the current function's stack frame. This may include the stored return address, causing execution to continue at an attacker-influenced location, or the stack and frame pointers, which can distort address calculations and memory operations. Consequently, the condition can cause crashes or data corruption and, in some circumstances, enable unauthorized code execution or bypass of the program's security policy.

The weakness affects a buffer located on the execution stack, usually a local variable and more rarely a function parameter. Security-sensitive stack data can be overwritten, including the stored return address, stack pointer, and frame pointer; altering these values can redirect execution, modify memory, or support writes to attacker-influenced locations. It commonly occurs in memory-unsafe languages, especially C and C++.

The most direct consequence is reduced availability through crashes, process termination or restart, excessive CPU or memory consumption, or other denial-of-service conditions such as an infinite loop. Depending on what stack data is overwritten, the weakness may allow memory modification, unauthorized code or command execution, and bypass of protection mechanisms across integrity, confidentiality, availability, and access control. Arbitrary code execution can in turn undermine other security services.

Use bounds checking on input and avoid dangerous functions such as gets; choose safer equivalent functions that check boundary errors. Use abstraction libraries to hide risky APIs, while recognizing that this is not a complete solution.

As defense in depth, enable compiler or compiler-extension protections such as Microsoft Visual Studio /GS, Fedora/Red Hat FORTIFY_SOURCE, StackGuard, or ProPolice. These canaries and range or index checks detect some overflows, but they do not cover every type and the usual response can still be application termination and denial of service.

As additional defense in depth, use Address Space Layout Randomization (ASLR), Position-Independent Executables (PIE), and, where applicable, module rebasing or prelinking to make executable and library addresses less predictable. These measures do not provide a complete solution because address disclosures and side-channel attacks may bypass ASLR, and ASLR for libraries cannot be used together with prelinking.

Fuzzing: Generate large numbers of random or algorithmically varied inputs and invoke the code dynamically to expose crashes, memory corruption, or resource consumption. This approach can produce repeatable test cases and is rated highly effective.

Automated static analysis: Use source-level or binary-level analysis to model data and control flow, then search for potentially vulnerable paths from input sources to sinks. This can find some instances without executing the program and is rated highly effective.

Automated dynamic analysis: Integrate runtime memory-safety checks during compilation, such as AddressSanitizer for C/C++. This approach has moderate effectiveness because inputs must reach the defective code, it may reduce performance, and it reports the error condition rather than the original programming mistake.

A representative example is CVE-2021-35395, involving stack-based buffer overflows in SFK for a Wi-Fi chipset used in IoT and embedded devices; it was identified by CISA KEV as exploited in the wild. This is a representative example, not an exhaustive list of vulnerabilities in this weakness class.