detecting-memory-leaks
Detects memory leak vulnerabilities by identifying unfreed memory allocations and missing cleanup in error paths. Use when analyzing long-running processes, resource management, or investigating memory exhaustion issues.
When & Why to Use This Skill
This Claude skill specializes in identifying and diagnosing memory leak vulnerabilities within software codebases. By systematically tracing memory allocation lifecycles and verifying cleanup procedures in complex error paths, it helps developers prevent resource exhaustion, improve system stability, and mitigate potential Denial of Service (DoS) risks in long-running applications.
Use Cases
- Investigating memory exhaustion: Analyze long-running processes to find the root cause of gradual performance degradation and increasing memory consumption.
- Security Vulnerability Assessment: Identify missing cleanup logic in error handling paths that could be exploited to trigger system crashes or DoS attacks.
- Automated Code Review: Scan C/C++ or resource-intensive code for unfreed allocations, missing deletes, or circular references in complex data structures.
- Resource Management Optimization: Ensure efficient memory usage and lifecycle management in resource-constrained environments like embedded systems.
| name | detecting-memory-leaks |
|---|---|
| description | Detects memory leak vulnerabilities by identifying unfreed memory allocations and missing cleanup in error paths. Use when analyzing long-running processes, resource management, or investigating memory exhaustion issues. |
Memory Leak Detection
Detection Workflow
- Identify allocation points: Find all malloc/calloc/realloc calls, new/delete pairs (C++), map allocation locations
- Trace allocation lifecycle: Use
xrefs_toto trace allocations, follow pointers through code, identify all free() calls - Check cleanup paths: Verify every allocation has a corresponding free, check all error handling paths, review exception handling, assess callback cleanup
- Assess impact: How much memory is leaked? How often does it leak? What's the cumulative impact? Can it cause DoS?
Key Patterns
- Missing free: malloc() without corresponding free(), calloc() without free(), new without delete (C++)
- Exception path leaks: allocations before exception-prone operations, missing cleanup in error handling, leaks in early returns
- Reference cycles: circular references in data structures, reference counting bugs, shared pointer cycles
- Long-lived allocations: allocations that never get freed, caches without size limits, accumulating data structures
Output Format
Report with: id, type, subtype, severity, confidence, location, allocation (function, address, size), leak path, leak scenario, leak size per call, frequency, exploitability, impact, mitigation.
Severity Guidelines
- HIGH: Large leaks in frequently called functions
- MEDIUM: Small leaks or infrequent allocations
- LOW: Minor leaks with limited impact
See Also
patterns.md- Detailed detection patterns and exploitation scenariosexamples.md- Example analysis cases and code samplesreferences.md- CWE references and mitigation strategies