/memory-safety-c-cpp

name: memory-safety-c-cpp
description: Reference vocabulary for memory-safety vulnerabilities in native C/C++ code — bug-class taxonomy, common arithmetic patterns that lead to corruption, dispatch-family discipline, type-confusion idioms, use-after-free patterns, and exploitability factors. Read when analyzing, hypothesizing, designing harnesses for, or triaging findings against C/C++ code with sanitizer support (ASAN/UBSAN/TSAN/MSan). Not applicable to managed runtimes (JVM, .NET) or scripting languages — those have their own skills.

Memory-Safety Bugs in C/C++

Reference vocabulary for native C/C++ code with sanitizer support. Catalogs the bug classes, patterns, and exploitability factors a memory-safety investigation needs to reason about.

Bug-class taxonomy

Identifiers below are the canonical IDs to use when naming a bug class in any artifact. Map each to the oracle that catches it and the root-cause CWE.

| Bug class | Oracle | Root-cause CWE | Where it lives | | ---------------------- | -------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------- | | `heap_overflow` | ASAN `heap-buffer-overflow` | CWE-122 | Read or write past a heap allocation | | `stack_overflow` | ASAN `stack-buffer-overflow` | CWE-121 | Read or write past a stack frame buffer | | `out_of_bounds_read` | ASAN OOB-read | CWE-125 | Generic OOB load — distinct from heap/stack only by site | | `out_of_bounds_write` | ASAN OOB-write | CWE-787 | Generic OOB store | | `use_after_free` | ASAN `heap-use-after-free` | CWE-416 | Pointer dereferenced after the allocation it pointed to was freed | | `double_free` | ASAN `attempting double-free` | CWE-415 | `free()` called twice on the same allocation | | `integer_overflow` | UBSAN `signed-integer-overflow` / `unsigned-integer-overflow` | CWE-190 | Arithmetic produces a value outside the type's range | | `type_confusion` | ASAN OOB or UBSAN `vptr` | CWE-843 | A value is interpreted as a different type than it was created with — frequently across vtable / dispatch-table boundaries | | `format_string` | ASAN OOB / UBSAN | CWE-134 | Attacker-controlled bytes reach the format-spec argument of a `printf`-family call | | `null_deref` | SIGSEGV (caught by ASAN as `SEGV on unknown address 0x000000000000`) | CWE-476 | Dereference of a pointer the attacker can force to NULL | | `uninitialized_memory` | MSan `use-of-uninitialized-value` | CWE-457 | Read of memory before it was written | | `race_condition` | TSAN `data race` | CWE-362 | Concurrent unsynchronized access (a TOCTOU is a special case where the racing accesses are check-then-use) | | `memory_leak` | LSan / ASAN leak report | CWE-401 | Heap allocation lost without `free()` |

**CWE precision rule.** Always cite the _root-cause_ CWE, not the _consequence_ CWE. An integer overflow that leads to an undersized heap allocation and a subsequent OOB write is CWE-190 (the arithmetic bug), not CWE-122 (the consequence). A `strncpy` using the wrong size constant is CWE-806 (buffer access using size of source buffer), not CWE-120 (generic buffer overflow).

Common arithmetic patterns that lead to corruption

These are the high-yield sites to look for whenever the surface processes attacker-controlled lengths, counts, offsets, or indices. Each is a _pattern_, not a procedure — the same pattern fires across many surfaces (parsers, codecs, compression, RPC framing, allocator wrappers).

• **Integer overflow into allocation size.** Attacker controls a count `n`. Code computes `n * sizeof(T)` (or `n + header`) and passes the result to `malloc`/`new[]`. The multiplication or addition wraps; the allocation is undersized; subsequent indexed writes overflow. The _named violation site_ is the multiplication or addition, not the OOB write — the OOB write is the consequence.

• **Signed/unsigned mixing at a comparison.** A signed integer is compared against an unsigned length (or vice versa). The signed value is implicitly converted to unsigned, turning negative values into very large positives. A "guard" of the form `if (i < len) ...` admits every negative `i` when `len` is unsigned.

• **Type narrowing at a storage boundary