memory-safety

name	memory-safety
description	Memory safety theory and practice, language-agnostic: spatial/temporal violation classes (buffer overflow, use-after-free, double-free, dangling pointers, uninitialized reads, type confusion), ownership and lifetime models (RAII, borrow checking, reference counting, GC, exclusivity), sanitizers (ASan/TSan/UBSan/MSan), and hardware mitigations (ASLR, W^X, stack canaries, PAC, MTE, CHERI). Use when reviewing unsafe/low-level code, diagnosing memory corruption or crashes (segfault, heap corruption, UAF), choosing ownership strategies, or hardening builds. For C bounds annotations use c-bounds-safety; for Xcode hardening settings use audit-xcode-security-settings.
allowed-tools	["Read","Glob","Grep","Bash"]

Memory Safety

IRON LAW: UNSAFE CODE IS GUILTY UNTIL PROVEN SAFE. EVERY unsafe/raw-pointer
BLOCK NEEDS A STATED INVARIANT: WHO OWNS IT, HOW LONG IT LIVES, WHAT BOUNDS IT.

Violation Classes (know what you're looking at)

Class	Kind	Typical symptom	CWE
Out-of-bounds read/write	Spatial	Corruption "far away", crash in unrelated code	CWE-125/787
Use-after-free	Temporal	Works in debug, crashes in release; heap corruption	CWE-416
Double free	Temporal	Allocator abort, exploitable heap state	CWE-415
Dangling stack pointer	Temporal	Garbage values after return	CWE-562
Uninitialized read	Initialization	Nondeterministic behavior, info leaks	CWE-457
Type confusion	Type	"Impossible" values, vtable crashes	CWE-843
Data race on shared memory	Concurrency	Heisenbugs; UB in C/C++/Swift	CWE-362

Memory corruption is the classic root of exploitable bugs (historically cited as ~70% of severe CVEs in large C/C++ codebases — the motivation for memory-safe-by-default languages).

Ownership & Lifetime Models (choose deliberately)

Model	Guarantees	Costs / hazards
Manual (C)	None — discipline only	All classes above
RAII + smart pointers (C++)	Scoped lifetime	UAF via raw this/views; iterator invalidation
Borrow checking (Rust-style)	Compile-time spatial+temporal	Learning curve; unsafe escape hatches
Reference counting (ARC/shared_ptr)	Temporal (while referenced)	Cycles leak — need weak refs; count traffic
Tracing GC	Temporal	Pauses/footprint; finalizer hazards
Exclusivity enforcement (Swift)	No overlapping read/write access	Runtime traps reveal aliasing bugs

Rules that hold in every model:

• One owner per allocation; everything else borrows. Document which is which at API boundaries (who frees? may the callee retain?).
• Never return/store a pointer or view (slice, span, string_view, buffer pointer) that can outlive its backing storage.
• Bounds travel WITH pointers (pointer+count as one unit — see c-bounds-safety for compiler-enforced annotations).

Sanitizers (run them; they're cheap insurance)

Tool	Catches	Notes
ASan (AddressSanitizer)	OOB, UAF, double-free	~2x slowdown; run unit tests under it in CI
TSan (ThreadSanitizer)	Data races	Mutually exclusive with ASan — separate CI job
UBSan	UB: overflow, misalignment, bad casts	Cheap; combine with ASan
MSan	Uninitialized reads	Clang, non-Darwin mostly; needs full rebuild
Fuzzing (libFuzzer/AFL) + ASan	Parser/decoder corruption	Pair with testing skill's fuzz guidance

Debug-only checks (allocator guard malloc, debug iterators) catch less than sanitizers — don't substitute one for the other.

Hardware & Platform Mitigations (defense in depth, not a fix)

• ASLR + W^X (DEP/NX): baseline everywhere; don't defeat with predictable mappings or RWX pages (JITs need careful design).
• Stack canaries / shadow stacks: detect return-address smashing.
• PAC (ARM pointer authentication, arm64e): signs return addresses and function pointers — see audit-xcode-security-settings (pointer-authentication reference).
• MTE (ARM Memory Tagging): probabilistic spatial+temporal detection via tagged pointers — see audit-xcode-security-settings (hardware-memory-tagging reference).
• CHERI capabilities: research/early deployment — pointers carry bounds and permissions in hardware.

Mitigations raise exploitation cost; the bug is still a bug. Fix root cause.

Language Notes

• Swift: memory-safe by default. The unsafe surface is explicit and greppable: Unsafe*Pointer, unsafeBitCast, unowned(unsafe), withUnsafe*, .assumingMemoryBound, C interop. Review checklist: bounds proven, lifetime pinned (withExtendedLifetime where needed), no escaping of withUnsafe* pointers from the closure, alignment respected. Exclusivity violations trap at runtime — they're real aliasing bugs, never "disable the check". Data races: Swift 6 strict concurrency makes them compile-time errors — see swift (concurrency).
• C/C++: prefer -fbounds-safety (see c-bounds-safety), hardened libc++, smart pointers, span types; ban naked new/malloc in new code.
• Kotlin/JVM: memory-safe runtime; the unsafe surface is JNI/native interop and sun.misc.Unsafe — apply the C rules there.

Review Workflow

1. Grep the unsafe surface (per language above) — inventory before reading.
2. For each unsafe site: state owner, lifetime, bounds invariant. Can't state it → finding.
3. Check error/early-return paths for cleanup (leaks, double-free) — the sad path is where temporal bugs live.
4. Confirm sanitizer coverage exists for the code path; recommend the missing CI job if not.

Related Skills

Need	Skill
C -fbounds-safety adoption	c-bounds-safety
PAC/MTE/Enhanced Security build settings	audit-xcode-security-settings
Exploit-relevant security review	secure-coding, apple-secure-coding
Cache/layout performance of memory	hardware-runtime
Swift ownership & layout specifics	swift (memory-layout-performance)