Return of Stack Variable Address

Draft Base
Structure: Simple
Description

This vulnerability occurs when a function returns a pointer to its own local variable. Since that variable's memory is on the stack, the pointer becomes invalid as soon as the function finishes, leading to crashes or unpredictable behavior.

Extended Description

When a function declares a local variable, it's stored in a temporary memory region called the stack. This stack space is only reserved for the lifetime of that function call. Once the function returns, its stack frame is cleared and that memory is marked as available for the next function call. If you return a pointer to this now-freed location, you're handing the calling code a 'dangling pointer' to a memory address that is no longer guaranteed to hold your intended data. The program may continue to run, but the next function that executes will likely reuse that same stack address for its own local variables, overwriting whatever value was there. Any subsequent attempt to read or write through the old pointer will access this new, unrelated data, causing corruption, logic errors, or most commonly, a sudden segmentation fault when the program tries to dereference the invalid pointer.

Common Consequences 1
Scope: AvailabilityIntegrityConfidentiality

Impact: Read MemoryModify MemoryExecute Unauthorized Code or CommandsDoS: Crash, Exit, or Restart

If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.

Detection Methods 2
FuzzingHigh
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Testing
Use static analysis tools to spot return of the address of a stack variable.
Demonstrative Examples 1

ID : DX-203

The following function returns a stack address.

Code Example:

Bad
C
c
Applicable Platforms
Languages:
C : UndeterminedC++ : Undetermined
Modes of Introduction
Implementation
Functional Areas
  1. Memory Management
Affected Resources
  1. Memory
Taxonomy Mapping
  • CERT C Secure Coding
  • CERT C Secure Coding
  • Software Fault Patterns