Rust and Memory Safety: Why Critical Software Is Moving Away from C and C++

According to long-term analyses by software vendors, approximately 70% of security vulnerabilities in large codebases are related to memory-handling errors. These aren’t complex attacks on encryption, but rather trivial mistakes: the program reads from or writes to the wrong location. The Rust programming language is designed to catch a large portion of such errors before the program even runs. This explains its rise in operating systems. However, this does not mean that Rust is flawless.

What Is Memory Safety and Why Does It Cause So Many Errors

How memory errors occur

In C and C++, programmers manage memory themselves: they determine when to allocate it, when to free it, and how long a pointer may point to it. If they make a mistake, two typical problems arise. In a buffer overflow, the program writes data outside the allocated space. In a “use-after-free” error, the program accesses memory that already belongs to another entity. An attacker can exploit such errors to crash the system or execute their own code.

How Rust Detects These Errors

Rust enforces ownership rules. Every value has exactly one owner, and when that owner is destroyed, the memory is freed. A value can be borrowed, but the rule is similar to borrowing a book: either multiple people can read it at once, or a single person can edit it—never both. This is enforced by a part of the compiler called the borrow checker. If a program violates these rules, it simply won’t compile. The error therefore occurs during compilation, not when the user runs the program.

What the Data Shows

The most frequently cited figures come from the Android mobile operating system. According to data from its developers, the proportion of vulnerabilities caused by memory errors fell from 76% in 2019 to 24% in 2024. At the same time, the total number of these vulnerabilities fell from more than 200 to fewer than 50. The authors attribute this decline to a set of practices called “Safe Coding,” which, in addition to Rust, includes other secure languages, static analysis, and safer interface design.

Another important finding is that legacy code was not rewritten. Vulnerabilities in it disappear over time as they are fixed or the code ages, which is why new bugs arise primarily in new code. If new code is written in a safer language, the number of bugs decreases. The claim that this is due solely to Rust itself should therefore be interpreted with this nuance in mind. Furthermore, developers report that changes written in Rust had to be rolled back less than half as often as changes in C++.

Rust in the Linux Kernel

Support for Rust was introduced into the Linux kernel in version 6.1 at the end of 2022 as an experiment: if it did not prove successful, it was to be removed. At a kernel maintainers’ meeting in 2025, participants agreed that the experiment was over and that Rust would remain in the kernel. The developer leading the project submitted a documentation update in this regard. One of the kernel maintainers noted that drivers written in Rust have so far proven to be significantly more secure than their C counterparts.

However, the scope is still limited. Rust is used in the kernel primarily for new drivers, and according to available data, it accounts for only a fraction of the kernel written in C. Code written in Rust is not yet compiled by default. The maintainer of the kernel’s graphics component has indicated that a ban on new drivers written in C could be in place in about a year, though this is his personal opinion and not an official decision.

The Transition of Large Companies: What Is the Plan and What Is the Vision

When it comes to large software companies, a distinction must be made. After a senior engineer announced that the goal was to eliminate every line of C and C++ from his company by 2030, an explanation followed: This is a research project by his team focused on automated code translation between languages, not a strategy to rewrite the entire operating system. The company already uses Rust in some parts of its code, but according to available information, it has no plans to completely rewrite the system. Decisions based on data today are therefore more incremental: new code is written in a safer language, while existing code is modified cautiously.

Pressure is also coming from government institutions. As early as 2022, the U.S. National Security Agency called on organizations to switch to languages with safe memory management, and more recent recommendations, issued jointly with CISA, reiterated this call.

Rust’s Limits: Where Security Ends

The `unsafe` block and the first vulnerability in the core

Rust also has a mode in which the compiler does not perform certain checks. It is indicated by the keyword unsafe and is necessary, for example, when communicating with C code. Here, the programmer assumes responsibility for correctness. In December 2025, the first vulnerability (CVE) assigned to Rust code in the Linux kernel was discovered. It involved a driver ported from C and was related to the unsafe. The reason this isn’t an argument against Rust is the ratio: on the same day, 159 CVE entries were issued for the C portion of the kernel.

What the Compiler Doesn’t Catch

Memory safety does not guarantee correct program logic. Faulty calculations, incorrectly configured permissions, or weak security can arise in any language. The transition also takes time: projects must give developers time to learn the new language, and the interface between old and new code is another risk area that Android developers view as one of the main challenges.

What This Means for the Average User

Users won’t notice the language change directly. The impact is indirect: systems, drivers, and components built on a more secure foundation should contain fewer vulnerabilities that can be exploited. The key factor remains how quickly the new code makes its way into products and how thoroughly the old code continues to be maintained and updated.

Conclusion

Rust addresses a specific and very common type of bug by shifting them from the runtime phase to the compilation phase. Data from Android and experience with the Linux kernel suggest that this works best with new code. However, the label “bulletproof” doesn’t quite fit: unsafe blocks, logical errors, and interfaces with existing code remain a risk. The reality, therefore, is a gradual transition, not a revolution.