How can 'safe' Rust still be unsafe? A tool that hunts the gap

A plain-language look at the paper “UnsafeChecker: Finding Soundness Bugs in Rust Safe Abstractions” (Yin, Zhang, Feng & Xu, 2026). This is the short version — the full breakdown, with the methodology and every result, lives here.

Rust makes a strong promise: a program that compiles without ever writing the word unsafe will not corrupt memory. However, that promise leans on the libraries underneath it, and those libraries are full of unsafe code. When one of them gets a single detail wrong, an ordinary program that never wrote a line of unsafe can still read freed memory, run off the end of a buffer, or be exploited. A recent paper from Nanjing University builds a tool, UnsafeChecker, to hunt for exactly these hidden mistakes — and reports 114 previously unknown ones in real, widely used crates.

In one sentence. UnsafeChecker reconstructs the three things Rust’s raw pointers throw away — who owns a value, whether it is still alive, and its physical layout (where it sits and how big it is) — and uses them to flag unsafe library code that would let ordinary safe code trigger undefined behavior.

How safe code can still break

Library authors hide their dangerous, low-level code behind ordinary, safe-to-call APIs — a safe abstraction such as Vec or Mutex. The arrangement is a contract: inside the wrapper, the unsafe code must uphold by hand the invariants the compiler would otherwise enforce. Break that contract and the abstraction is unsound — safe callers who never wrote a line of unsafe can still hit undefined behavior: out-of-bounds reads, use-after-free, double frees, and the exploits that follow.

An analogy that maps onto the mechanism. Picture an automated warehouse where every item has three facts on file: who holds its single claim ticket (ownership), its status stamp — stocked, shipped, incinerated (lifecycle), and its physical footprint on the shelves (layout). A raw pointer is a bare shelf coordinate on a sticky note, with none of those three facts attached. UnsafeChecker is the auditor who walks the floor and rebuilds the manifest from those coordinates, then flags any operation that would reach past an item, touch one already incinerated, or photocopy a claim ticket so two parts of the program each try to dispose of the same item.

Why it matters

The whole Rust ecosystem is built on trusting that these unsafe-inside wrappers keep their promises. UnsafeChecker is a compiler plugin that rebuilds ownership, lifecycle, and layout from raw pointers, carries all three in one shared state as it walks the code, and checks two things: dangerous operations as they happen, and — this is the part a pattern-matcher cannot do — whatever leaks back out through the safe API at each function’s exit. On a benchmark of 46 real CVEs it caught 32 (69.6%), against 11 for the best prior tool, finding more than 20 that every baseline missed. Then it scaled to 100,000+ crates in two days and surfaced 114 real, previously unknown bugs; maintainers have already fixed 27, and 11 have public vulnerability identifiers.

It is not magic. About half its alerts are false alarms (51.6% precision), it misses roughly a third of the benchmark bugs, and it does not touch concurrency. It is a fast, sharp bug-_finder_ for the authors of unsafe-heavy libraries — not a proof of soundness.

The one thing to remember

“Safe Rust” is a promise your libraries make on your behalf. Most keep it. Tools like UnsafeChecker are how we find the ones that quietly do not — before an attacker does.

---

Want the details — the full three-domain methodology, the complete results, a compile-checked code example, and the open questions? Read the full summary.

Produced by a multi-agent pipeline I built with Claude — drafted, independently fact-checked, edited for writing, and rewritten in my own voice — then reviewed by me before posting. The plots are my own, from the paper's reported numbers.