Rust exists to make one family of bugs impossible. Use-after-free, double free and buffer overflow are the failures behind three decades of critical vulnerabilities. Rewriting a working C codebase by hand is expensive enough that a small field of automatic C-to-Rust tools has grown up to do it, and they all report success the same way, by how much of the output they got out of Rust's unsafe blocks. Less unsafe, safer code. That assumption is what this study set out to test.
Four of the leading tools were run over just over a hundred small C programs from a standard security test suite, each holding one known memory bug. Most of what came back wouldn't compile. A coding model given a few passes at the build errors rescued nearly all of it. Of the versions that did compile, the original memory bug was still present in more than four in ten. The tools also introduced 77 bugs that had no counterpart in the C they started from.
"Our findings indicate that current automated refactoring tools deliver memory safety as they define it, but not the broader memory security when adopting them."
One result lands in both columns at once. A common way these tools neutralise a C memory bug is to convert silent corruption into a crash, a Rust panic, loud and traceable, which the study counts as a mitigation. But an incremental migration means the rewritten function still gets called from the C nobody has touched yet, and a Rust panic unwinding into a C stack frame is itself undefined behaviour. The same change can be a fix and a new vulnerability, depending only on who calls it. Panics crossing that boundary were the largest single category of new bugs in the study.
The authors trace the failures to design decisions rather than bad luck. One tool rolls an entire function back to its unsafe original when it can't get the safe version to build, discarding every improvement to keep the compiler happy. Another downgrades its own analysis to raw pointers as the code gets more complicated. The model-driven tool gets a prompt listing six requirements, among them "uses safe rust". It ignores them. The check afterwards is a search of its output for the word unsafe.
What the study can't say is how any of this behaves on real code. The programs are synthetic and single-purpose, one textbook bug each, and the authors are candid that they tried real code and the tools couldn't parse OpenSSL or radare2 at all. These were the easy cases. The failure rate on a production repository is unmeasured, not lower.
Two things follow for anyone being sold a migration. On this evidence, a tool's headline number (the share of unsafe it eliminated) describes the shape of the code, not its security, so the question to put to a vendor is which classes of vulnerability stopped reproducing. That is cheap to check. Point the memory-bug detection already aimed at the C at the Rust instead, and see whether the issues you know about still fire. The second is where review attention belongs. The riskiest part of a half-migrated codebase is the seam, not either side of it. Half-migrated is what most of these projects will be for years.
"Until refactoring tools treat security as a design constraint rather than an emergent property of reducing unsafe code, developers should continue auditing the output Rust program."
Sources
- Chen, H., He, X., Lu, B. et al., "C-to-Rust Fallacy: Automatic Refactoring != Memory Security" — https://arxiv.org/abs/2609.25682