Google Uses Gemini and Differential Fuzzing to Rewrite C Library in Rust, Fixing Zero-Day

Google's security team used Gemini to automatically translate giflib (3,000 lines of C) into an ABI-compatible Rust implementation, fixing a zero-day heap write vulnerability, eliminating the sandbox without increasing latency. This approach employs a three-stage feedback-driven migration process, balancing memory safety with production readiness.

Gemini-assisted migration preserves original exported symbols and struct definitions for seamless replacement; FFI modeling requires manual calibration of ownership and lifetimes and cannot be fully automated; a differential testing engine drives model iteration to fix behavioral deviations.

Suitable for security engineers, systems programmers, and language migration architects.

Google's security team has validated a new path to eliminate memory vulnerabilities in legacy infrastructure—using Gemini to translate C codebases into memory-safe Rust equivalents. The project targeted giflib, an image processing library of approximately 3,000 lines of code that frequently decodes untrusted user input without sandbox isolation. The team wrote a Rust library that is ABI-compatible and directly replaceable, disabling the process isolation sandbox, maintaining original latency, and fixing an unpatched zero-day heap write vulnerability before it was publicly cataloged as CVE-2026-26740.

Memory corruption vulnerabilities account for roughly 70% of high-severity security flaws in mature C/C++ code stacks. Software engineers Bastian Kersting and Max Hils did not choose time-consuming manual porting lasting years, nor did they rely entirely on runtime boundary checks. Instead, they designed a three-stage automated migration process centered around autonomous feedback loops.

First, the team used one-shot prompts to have Gemini port the complete logic of the C library to Rust. Since the library needed to transparently replace existing shared objects without breaking downstream callers, engineers preserved the original exported symbols and struct definitions. In the initial implementation rounds, Foreign Function Interface (FFI) modeling introduced unsafe raw pointer semantics, requiring manual inspection and refinement of pointer ownership and lifetime invariants. Finally, an automated differential testing engine detected behavioral differences and fed failing execution traces back to the model to iteratively generate patches.

To avoid undefined behavior when passing pointers across C boundaries, the FFI wrapper layer reconstructs safe Rust handles from raw pointers:

#[no_mangle]pub unsafe extern "C" fn DGifCloseFile(    gif_file: *mut GifFileType,    error_code: *mut c_int,) -> c_int {    if gif_file.is_null() {        return GIF_ERROR;    }    let mut handle = Box::from_raw(gif_file as *mut GifFilePrivate);    match handle.close() {        Ok(_) => GIF_OK,        Err(e) => {            if !error_code.is_null() {                *error_code = e.to_raw();            }            GIF_ERROR        }    }}

Copy Code

Deploying auto-generated code to core business infrastructure requires proving semantic equivalence with the original C implementation. The team built a validation pipeline performing large-scale regression decoding tests on over 30 million real GIF files, ensuring bit-for-bit rendering consistency.

Simultaneously, an automated differential fuzzer ran side-by-side iterations of both runtimes continuously for six days, accumulating 200 million iterations without discovering functional drift. The test suite also included adversarial LLM evaluation prompts to analyze both code repositories for potential behavioral divergences. This validation pipeline uncovered an unhandled edge case in the LZW decompressor and flagged an internal legacy out-of-bounds write vulnerability—a problem introduced by an early internal patch to the original C source code.

The project's strongest validation occurred during the pre-release phase. An external security researcher discovered an out-of-bounds heap write vulnerability in upstream giflib, later cataloged as CVE-2026-26740. Before public disclosure, Google's production nodes running the Rust alternative were fundamentally immune to this vulnerability at the architectural level, demonstrating that language-level migration can preemptively eliminate entire classes of vulnerabilities.

When replacing C libraries with Rust, concerns often arise about runtime overhead from mandatory boundary checks. Production monitoring data from global image decoding clusters showed that the Rust binary performed on par with the original C program. Moreover, memory safety guarantees were moved directly into the type system, allowing platform engineers to remove the traditional OS sandboxes previously set up to isolate image decoding tasks. After removing this process isolation boundary, P99 tail latency decreased significantly.

Despite performance improvements, the authors note that AI code translation is not a silver bullet that can be left completely unattended. Forking upstream C dependencies into Rust libraries introduces ongoing maintenance forks whenever upstream releases new features or architectural changes. Additionally, FFI wrappers still require domain expert intervention to prevent lifetime leaks and ensure thread safety constraints are not violated.

r/rust and Hacker News discussions generally acknowledged this achievement while debating the practicality and safety of AI-assisted porting. Commenters praised Google’s rigorous differential fuzzing framework, which uncovered a pre-existing out-of-bounds write vulnerability in Google’s own legacy C patches. However, many questioned the "one-shot direct translation" approach, noting that manually auditing subtle semantic regressions and fixing unsafe C FFI boundaries often requires significantly more effort than code generation itself. Many argued that for codebases larger than simple, self-contained projects like giflib, using deterministic transpilers (such as c2rust) followed by AI-driven refactoring into safe, idiomatic Rust would be more reliable.

Google has open-sourced the generated library under the name giflib-rs, serving as a reference implementation for teams considering automated language migration for foundational tools.

View the original English article: https://www.infoq.com/news/2026/09/c-rust-rewrite/