/native-code-review

name: native-code-review
description: "Review C, C++ and Rust source for memory-safety bugs: out-of-bounds reads and writes, integer overflow or truncation that feeds a size, use-after-free and double free, format strings, uninitialized memory, Rust unsafe soundness, FFI boundaries, parsers of untrusted input, and secrets left in memory. Also checks compiler hardening flags and recommends sanitizers, and reports in the shared findings.json format. Use when the user mentions 'native code review,' 'C code review,' 'C++ security review,' 'memory safety review,' 'buffer overflow,' 'use-after-free,' 'double free,' 'format string bug,' 'integer overflow,' 'uninitialized memory,' 'unsafe Rust,' 'is this unsafe block sound,' 'FFI boundary,' 'Miri,' 'AddressSanitizer,' 'checksec,' 'FORTIFY_SOURCE,' 'hardening flags,' 'explicit_bzero,' or 'zeroize.'"
allowed-tools: Read, Grep, Glob, Bash(readelf:*), Bash(checksec file:*)

Native Code Review — C, C++ and Rust Memory Safety

Review native source for the bugs that only memory-unsafe code has: a length that outgrows its buffer, a pointer that outlives its object, a format string the caller controls, bytes read before anyone wrote them, and Rust `unsafe` that quietly breaks the guarantees safe code relies on. Parsers of untrusted input come first. Every candidate is traced from where untrusted bytes enter to the memory operation that goes wrong, then challenged before it becomes a finding.

Cross-references: `crypto-audit` (timing leaks and constant-time code in crypto paths, algorithm and parameter choice), `owasp-audit` (web and application logic, including command injection a native service shares with any other), `dependency-audit` (known CVEs and RustSec advisories in the libraries and crates you link), `vuln-research` (whether a published CVE in a C library is reachable from your code), `mobile-audit` (JNI and native libraries inside an Android or iOS app), `container-audit` (the image the binary ships in), `finding-triage` (one finding to a disposition).

When to use

• "Review this C parser / C++ daemon / Rust crate for memory safety"
• A pasted function with `memcpy`, `malloc(n * size)`, `printf(buf)`, `unsafe { ... }`, `set_len`, `transmute`,

`from_raw_parts` or an `extern "C"` block, and the question "is this safe?"

• A Rust crate's `unsafe` blocks, `Send`/`Sync` impls or FFI layer, before release or before depending on it
• Secrets that should be wiped from memory (keys, passwords, tokens) in C, C++ or Rust
• Whether a binary was built with hardening flags (`checksec`, `readelf`), and which flags and sanitizers to add
• Input: a repo or directory, a diff, or a pasted snippet. A built binary is optional and only used read-only

**Not for:** constant-time comparison, timing side channels in crypto code, or cipher and KDF choices → `crypto-audit`; web routes, auth and injection in a service that happens to be written in C++ or Rust → `owasp-audit`; "is our OpenSSL / zlib / libpng version vulnerable?" → `dependency-audit`, then `vuln-research` for reachability; Go, Java, Python or JavaScript code (memory-safe runtimes) → `owasp-audit`; reverse engineering or analyzing a binary you don't have source for, malware analysis, or kernel exploitation research (out of scope).

Authorization

• Review only source and binaries the user owns or is authorized to audit. If the code is a third party's and you

find a bug, say so and point at the project's security policy (see Boundaries).

• **Read-only steps:** reading and grepping source, build files and CI config; `readelf` and `checksec file` on

binaries already built in the repo or handed to you. Both only read the file.

• **Needs a yes first:** building the project, running its tests, sanitizer builds, Miri, `cargo geiger`, a fuzzer or

any harness. Building runs the project's build scripts (`build.rs`, CMake, `configure`) and running tests runs its code, so get the go-ahead first and prefer a container or VM the user controls. Install toolchains only when the user says to.

• **Stops at proof of the invariant.** A sanitizer report, a Miri error or a crash on a minimal input is the end of

dynamic work. Don't develop it further into control of execution, and don't run anything against systems or binaries outside the authorized scope.

Workflow

1. **Scope**: languages, build system, targets, where untrusted bytes come from 2. **Map the surface**: entry points, parsers, FFI boundaries, unsafe inventory 3. **Hunt by bug class**: priority targets first, using the catalog 4. **Rust unsafe soundness** (Rust code only) 5. **Secrets in memory** 6. **Binary hardening**: flags in the build, then the built artifact 7. **Dynamic confirmation**: sanitizers, Miri, fuzzing hand-off (with a yes) 8. **Verify, then record**

For a diff or PR, run the same steps on the changed functions, plus every caller that now passes new input into an old memory operation.

Step 1 — Scope

git ls-files | grep -cE '\.(c|h)$'; git ls-files | grep -cE '\.(cc|cpp|cxx|hpp|hh)$'; git ls-files | grep -c '\.rs$'
ls CMakeLists.txt Makefile meson.build configure.ac Cargo.toml build.rs compile_commands.json 2>/dev/null
git ls-files | grep -iE '(fuzz|corpus)' | head    # existing fuzz targets and seed inputs
grep -rnE 'fsanitize|-Zsanitizer|miri' .github .gitlab-ci.yml CMakeLists.txt Makefile 2>/dev/null | head

Write down, before hunting:

• **Who supplies the bytes**: network peer (pre- or post-auth), a file the user opens, another process over IPC, a

less-privileged local user (setuid, daemon running as root), a plugin, or only the program's own config

• **Targets**: architectures and word size (a 32-bit build changes which integer overflows are reachable),

compiler, libc, Rust edition and MSRV

• **Out of scope**, with a reason: vendored third-party code (→ `dependency-audit`), generated code, test-only code

Step 2 — Map the surface

Untrusted input decides priority. Map where it enters, t