Google has pushed memory safety deeper into smartphone hardware with Pixel 10, replacing the cellular modem’s legacy DNS parser with a Rust-based implementation designed to block a class of bugs long associated with buffer overflows, out-of-bounds access and remote code execution. The change, disclosed by Google’s security engineers on April 10, marks the first time a Pixel device has used a memory-safe language inside the modem itself, a part of the handset that sits on a broad remote attack surface because it processes data from mobile networks. Move matters because the baseband remains one of the least visible yet most security-sensitive components in any handset. While consumers tend to focus on app security and operating-system patches, the modem handles continuous exchanges with telecom networks and parses untrusted external input. Google said attackers and researchers have shown sustained interest in that layer, and pointed to earlier Project Zero work demonstrating remote code execution against Pixel modems over the internet. That history helps explain why the company is treating even a narrow component swap as a strategic security milestone rather than a routine engineering upgrade.
Google’s engineers chose DNS because the protocol is both essential and exposed. DNS is widely recognised as the system that translates domain names into network addresses, but in modern cellular networks it also underpins functions such as call forwarding and other data-driven services. Parsing DNS responses means handling complex, untrusted data, and Google argued that doing so in a memory-safe language removes an entire class of weaknesses from a risky part of the modem stack. In practice, that does not mean every modem flaw disappears, but it does mean one important parser no longer depends on the same memory-unsafe assumptions that have dogged low-level firmware for decades.
Technical details released by Google show this was not a ground-up modem rewrite. The company selected the open-source Rust crate hickory-proto after evaluating available DNS libraries, citing its maintenance, adoption and test coverage. Because modem firmware runs in a bare-metal style environment, engineers had to add no_std support so the code could operate without Rust’s standard library. They also wired the new parser into existing C and C++ modem code through foreign-function interfaces, allowing Rust to process DNS responses while older code continues to manage other in-memory structures and callbacks.
Trade-offs came with the shift. Google’s own size study put the added footprint at about 371KB, including the Rust shim, the hickory-proto library, dependencies and required runtime components. That overhead was judged acceptable for Pixel phones because the modem is not tightly constrained for memory, but Google acknowledged the same expansion could be harder to justify in smaller embedded systems. Engineers also had to resolve build and linking problems as the Rust component was integrated into the existing firmware pipeline, underscoring a broader industry reality: adopting memory-safe languages in legacy low-level systems is usually incremental, not clean-sheet.
Broader context strengthens Google’s case. Android’s security documentation says memory-safety bugs have historically accounted for more than 60% of high-severity vulnerabilities in Android codebases, while Google said in November 2025 that memory-safety issues had fallen below 20% of total Android vulnerabilities for the first time as Rust adoption expanded. In the same update, Google reported a sharp reduction in vulnerability density for Rust compared with C and C++ inside Android development. Those figures do not prove Rust is a cure-all, and even Google has cautioned against treating memory-safe languages as a panacea, but they do provide measurable support for the company’s long-running argument that safer defaults reduce both risk and engineering drag.
Security specialists and policymakers have been moving in the same direction. A June 2025 joint paper from NSA and CISA argued that memory-safe languages can prevent entire classes of vulnerabilities, while also acknowledging the cost and complexity of introducing them into large legacy codebases. That balanced view matches what Google appears to be doing with Pixel 10: targeting high-risk components first, preserving interoperability with older code, and accepting that practical adoption will happen module by module. For smartphone makers, that approach may prove more realistic than promising wholesale rewrites of modem firmware that has accumulated over many hardware generations.
Topics
Technology