Google didn’t just build a new modem for the Pixel 10. It rebuilt the way the modem’s software defends itself — by injecting Rust into a codebase that was never designed for it.
The effort, disclosed in detail by Google’s security team in late April 2026, represents one of the most ambitious real-world deployments of Rust inside legacy firmware. Not a greenfield project. Not a clean-sheet design. Google took an existing, shipping cellular baseband — the Exynos Modem 5400, manufactured by Samsung — and systematically introduced Rust components into its C and C++ firmware stack. The goal: eliminate entire categories of memory-safety vulnerabilities in one of the most attack-prone components of any smartphone.
The results, according to Google, speak for themselves. Memory-safety bugs in the modem firmware dropped to near zero in Rust-written modules. And the integration happened without rewriting the entire codebase — a constraint that made the project both harder and more instructive for the broader industry.
Why the Modem Is the Soft Underbelly of Every Phone
Cellular basebands are, by nature, exposed. They process untrusted input from cell towers constantly, parsing complex protocol stacks that have accreted layers of specification over decades — from 2G through 5G NR. A vulnerability in the baseband can be exploited remotely, without any user interaction, often before the application processor even knows something is wrong.
This isn’t theoretical. Baseband exploits have been demonstrated repeatedly by security researchers and reportedly used by surveillance vendors. Google’s own Project Zero has documented critical bugs in Samsung’s Exynos modems. The attack surface is vast: protocol parsers, codec handlers, state machines managing handovers between cell towers. All written, historically, in C or C++. All riddled with the kinds of buffer overflows, use-after-free errors, and out-of-bounds reads that memory-unsafe languages make trivially easy to introduce.
Google’s Android Security team, writing on the company’s security blog, framed the problem bluntly. The modem firmware is “one of the most security-critical components” on the device, they said. It runs on a separate processor with its own real-time operating system, often with direct memory access to the main system. A compromised baseband can mean a compromised phone — full stop.
So Google decided to do something about it. Not by replacing Samsung’s modem. Not by rewriting the firmware from scratch. By finding a way to make Rust coexist with millions of lines of existing C/C++ code.
As Ars Technica reported, the company “shoehorned” Rust into the Pixel 10’s modem firmware — an apt description for what was, by all accounts, a painstaking integration effort. The word “shoehorn” captures the reality: this wasn’t a codebase that welcomed a new language. It had to be made to accept one.
The technical challenges were significant. Baseband firmware runs on bare-metal or minimal RTOS environments, not Linux. There’s no standard library in the way Rust developers typically expect. Memory allocators behave differently. The build systems are proprietary. And the existing C/C++ code couldn’t simply be thrown away — it represents years of carrier certification, protocol compliance testing, and field-proven behavior that no one wanted to risk destabilizing.
Google’s approach was surgical. Engineers identified the highest-risk components — primarily parsers handling incoming network messages — and wrote new implementations in Rust, or wrapped existing C functions with Rust-based safety boundaries. The Rust code uses Foreign Function Interface (FFI) bindings to interoperate with the surrounding C/C++ firmware. This means the Rust modules can call into legacy code and be called by it, while maintaining Rust’s memory-safety guarantees within their own boundaries.
The team also had to work within the constraints of the modem’s real-time requirements. Cellular basebands operate under strict timing deadlines — a missed scheduling window can drop a call or fail a handover. Rust’s zero-cost abstractions helped here; the language imposes no runtime overhead compared to equivalent C code, so performance wasn’t sacrificed.
One of the more interesting technical details: Google used Rust’s no_std mode, which strips away the standard library and allows the language to run in bare-metal environments. This is the same approach used in embedded systems and operating system kernels — it’s how Rust found its way into the Linux kernel starting in 2022. But applying it inside a commercial cellular baseband, with all the associated certification and interoperability requirements, is a different order of complexity.
The Numbers — and What They Mean for the Industry
Google reported that memory-safety vulnerabilities in Rust-written modem components dropped effectively to zero. That’s not a marginal improvement. In the modules where Rust replaced C/C++, the entire class of bugs that has historically dominated baseband security advisories simply vanished.
This tracks with broader data Google has published about Android. In 2024, the company reported that memory-safety bugs in Android had dropped by 52% over several years, driven largely by writing new code in memory-safe languages rather than rewriting old code. The modem work extends that same philosophy to firmware — a domain where the industry has been slower to adopt modern languages.
The implications are substantial. Every major smartphone vendor ships devices with cellular basebands from a handful of suppliers: Qualcomm, Samsung (Exynos), MediaTek, and Intel (for some Apple modems). These basebands all run firmware written overwhelmingly in C and C++. If Google can demonstrate that Rust integration is feasible in this environment — without breaking carrier certification, without degrading performance, without requiring a full rewrite — it creates a template others can follow.
And Google clearly wants them to follow. The company’s blog post was detailed enough to serve as a technical roadmap, describing the FFI patterns, the build system modifications, and the testing strategies used to validate the Rust components. This is Google doing what it often does: solving a problem for its own products, then publishing the methodology to push the industry forward.
Samsung’s role here is worth noting. The Exynos Modem 5400 is Samsung’s hardware, and the base firmware is Samsung’s code. Google worked with Samsung to integrate Rust into this firmware for the Pixel 10’s Tensor G5 system-on-chip. The collaboration suggests Samsung is at least open to memory-safe language adoption in its modem stack — a significant signal given that Samsung supplies basebands for its own Galaxy devices as well.
Whether Qualcomm, which supplies modems for the majority of Android phones worldwide, will pursue a similar path remains an open question. Qualcomm has made some public statements about exploring Rust for certain firmware components, but nothing as concrete as what Google has shipped.
The broader Rust-in-firmware movement is gaining momentum beyond phones. The Rust-based Hubris operating system from Oxide Computer is running in production data center hardware. The Tock embedded OS uses Rust for microcontroller platforms. And the U.S. government’s CISA and NSA have both issued guidance urging software manufacturers to adopt memory-safe languages, citing the persistent dominance of memory-safety bugs in critical vulnerabilities.
But modems are a particularly hard target. The certification requirements alone are daunting — carriers and regulatory bodies require extensive testing before any modem firmware change ships. Introducing a new programming language into that process adds risk that most vendors have been reluctant to accept. Google’s willingness to absorb that risk, and its success in doing so, may lower the barrier for others.
There’s a pragmatic lesson here that extends well beyond mobile. The old assumption — that legacy C/C++ codebases are too entrenched to benefit from memory-safe languages — is increasingly being disproven. You don’t have to rewrite everything. You identify the attack surface. You target the riskiest components. You introduce safety incrementally, at the boundaries where untrusted input enters the system. That’s exactly what Google did with the Pixel 10 modem.
It’s not glamorous work. No one’s going to put “Rust in the baseband” on a marketing slide at a product launch. But for the security engineers who spend their careers chasing buffer overflows in protocol parsers, this is the kind of structural improvement that actually moves the needle. One component at a time. One fewer class of bugs to worry about.
And for the millions of Pixel 10 users who will never know any of this happened — that’s precisely the point.
WebProNews is an iEntry Publication