Is memory-safe Linux within reach?

How much of the kernel can be compiled with memory safety.

Yesterday I wrote about making programs memory-safe by checking at runtime, rather than at compile-time, using Fil-C. I hinted at Fil-C making it possible to actually make the Linux kernel memory-safe, but didn’t quite finish the section I wanted to write. So here it is.

Most Linux vulnerabilities come from memory corruption

For normal C/C++ code, about 70% of the vulnerabilities are due to memory corruption. In the Linux kernel, the ratio is even more skewed. In 2025 so far, 81% of Linux kernel vulnerabilities are memory corruption errors of the kind that Fil-C would prevent.

I determined this by examining the reported 2025 CVEs in the “Overflow” and “Memory Error” categories:

• The “Memory Error” category has 1132 CVEs, and I asked Claude to read 104 of them (the first four pages) and categorize them. From this sample, 62 were use-after-free, 23 were NULL pointer dereference, and 4 were buffer overflows. All of these were potentially preventable with Fil-C. This amounts to a ~85% of examined CVEs in this category being preventable, amounting to an estimated 962 CVEs.

• The “Overflow” category has 89 CVEs. 53 of them are integer overflows and 6 are both integer and buffer overflow. The other 30 are buffer overflows. Thus in total, 991 out of 1221 Linux CVEs were memory corruption errors.

Possible solutions

Rust in Linux

Rust for Linux is currently used only for drivers. In 2020, the project to add Rust to Linux started, the first driver landing in 2023. It is currently 2025 and Linux has a handful of Rust drivers, including notably the Mac M1 GPU driver. My assessment is that it will remain confined there for a long time.

But even now, probably for the sake of platforms other than x86_64 and arm64, it is an explicit requirement that Linux be possible to compile with no Rust at all. Rust is therefore confined to optional drivers, and will likely remain so for many years.

It’s possible that a fork could gradually replace parts of the kernel with Rust equivalents. But accurately reproducing all the tacit knowledge in the Linux code will be difficult. Maintaining the rusty fork in the face of an upstream kernel that rejects non-optional Rust code will be very burdensome.

Fil-C compilation

Instead, we can compile the kernel with Fil-C, which has all the same functionality as C. To be clear, this is not currently possible, but I believe joint changes to Fil-C and the kernel can make it possible.

There is no reason (other than performance) for which the kernel cannot bounds-check its pointer accesses or employ garbage collection. Indeed, Linux already has garbage collection in the RCU subsystem. Some have previously had vulnerabilities, so to be properly secure the Fil-C garbage collector would need to be audited, but it is doable.

Some subsystems of the kernel for which we can add bounds checks:

• Early boot: is almost certainly not possible to compile as safe. However, it’s possible to write a very small unsafe booting utility which starts the Fil-C runtime (garbage collector) and lets us bounds-check the rest.

• Drivers, filesystem: many are not performance critical, so nothing wrong in principle. Drivers sometimes need to write to particular memory addresses that have not been malloc’d, but we can deal with that by extending Fil-C to allow directly constructing pointers with their bounds.

• Security subsystems: SELinux, AppArmor, capabilities system

• Namespaces: a crucial feature for container isolation in Kubernetes and similar technologies.

Other systems I think would work except for performance: io_uring, networking, memory management, scheduler, spinlock and mutex definitions,

For others it might just be impossible to use Fil-C. In particular, code that handles interrupts has restrictions on how to allocate memory which might make it very hard.

To do this, it needs to be possible to intermix classically unsafe (Yolo-C) code and Fil-C code, though ABI-compatibility is not quite necessary because they can be compiled together.

Unsafe code: eliminated