CULPA: Unsafe Rust Memory Safety

Overview

This series explains how CULPA analyzes memory-safety obligations in unsafe Rust. It starts with Rust’s responsibility boundary, separates five requirements—bounds, non-nullness, alignment, initialization, and exclusive aliasing—then follows a proof from documented contract to executable predicates, memory segments, safeguards, invalidation, and public reachability. Examples involving Vec::set_len, type reinterpretation, UTF-8, and arrow-arith show why a nearby check or an unsafe marker is not enough. The study reports useful findings in selected package and advisory corpora, but its results are not a proof of completeness: 270 of 1,000 scanned packages failed before analysis, and domain invariants, FFI, concurrency, and other behaviors remain outside or beyond the model.

Learning outcomes

unsafe marks a responsibility boundary; it permits operations but does not prove their preconditions.
CULPA checks whether bounds, nullness, alignment, initialization, and aliasing evidence remains valid for the same memory region.
Its predicates, memory segments, and Requirement Graph connect contracts to safeguards, invalidation, and public reachability.
The study shows practical usefulness, not universal completeness: scope gaps, failed analyses, and false positives remain.

Keywords

CULPARustunsafememory-safetycontractspointerspredicatesprovenanceinvariantsreachability

Chapters

CULPA: Rust’s Unsafe Boundary

What the compiler keeps and callers must prove

11 min · What the compiler keeps and callers must prove

11 min

CULPA: Who Proves Unsafe Rust?

Compiler guarantees versus delegated obligations

10 min · Compiler guarantees versus delegated obligations

10 min

CULPA: Five Unsafe Rust Requirements

Separate bounds, nullness, alignment, values, and aliasing

10 min · Separate bounds, nullness, alignment, values, and aliasing

10 min

CULPA: Unsafe Calls as Proof Ledgers

Track conditions, objects, evidence, and invalidation

10 min · Track conditions, objects, evidence, and invalidation

10 min

CULPA: Executable Rust Safety Contracts

How predicates emit evidence for later operations

10 min · How predicates emit evidence for later operations

10 min

CULPA: Tracking Rust Memory Segments

Follow regions, aliases, and safeguards through code

11 min · Follow regions, aliases, and safeguards through code

11 min

CULPA: When Warnings Become Vulnerabilities

Evaluation denominators, false positives, and maintainer confirmation

11 min · Evaluation denominators, false positives, and maintainer confirmation

11 min

What CULPA Proves—and What It Cannot

Usefulness, limits, and layered safety evidence

12 min · Usefulness, limits, and layered safety evidence

12 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

What does unsafe mean in Rust?

unsafe means Rust has delegated an extra safety condition to the programmer, caller, implementer, or maintainer; it does not certify the operation.

How does CULPA detect memory-safety bugs in unsafe Rust?

CULPA translates documented requirements into predicates, tracks relevant memory segments and safeguard history, and checks whether a reachable unsafe operation lacks valid evidence.

What are CULPA’s five safety requirements?

CULPA models InBound, NonNull, Alignment, Initialization, and ExclusiveAlias; one operation may require several, and the advisory corpus contained no ExclusiveAlias case.

Does a CULPA warning prove a vulnerability?

No. In the study, manual inspection classified 55 of 107 candidates as true positives, 23 as in-scope false positives, and 29 as out-of-scope FFI cases.