Memory Corruption Detection

Detection Workflow

1. Identify memory operations: Find all malloc/free/realloc calls, stack buffer allocations, pointer arithmetic operations
2. Trace memory usage: Use

   xrefs_to

   to trace data, track pointer values through code, identify all access patterns
3. Check bounds: Verify size calculations, check array index validation, assess pointer arithmetic safety
4. Assess impact: Can corruption control execution? Is there information disclosure? Can corruption cause DoS?

Key Patterns

• Heap overflow: malloc() followed by unchecked writes, off-by-one errors, integer overflow in size calculations
• Stack smashing: large stack buffer allocations, unchecked array access, variable-length arrays, return address overwrites
• Pointer arithmetic: pointer arithmetic without bounds checking, array indexing with user-controlled indices, out-of-bounds pointer access
• Memory leaks: missing free() after malloc(), reference cycles, exception paths skipping cleanup

Output Format

Report with: id, type, subtype, severity, confidence, location, allocation (function, address, size), corruption (function, address, source), vulnerability, root cause, exploitable, attack scenario, mitigation.

Severity Guidelines

• CRITICAL: Memory corruption allowing code execution
• HIGH: Memory corruption with data corruption or DoS
• MEDIUM: Memory leaks or minor corruption
• LOW: Potential issues with limited impact

See Also

• patterns.md

  - Detailed detection patterns and exploitation scenarios

• examples.md

  - Example analysis cases and code samples

• references.md

  - CWE references and mitigation strategies