Oxidizing the OS: Ubuntu 26.10 completes the move to Rust coreutils

The commands look and feel exactly the same — ls, cat, cp, rm, all where you left them. Underneath, Ubuntu has quietly swapped the decades-old C foundation of the operating system for a memory-safe Rust one. Here is what changed, why, and who is unhappy about it.

With Ubuntu 26.10 (Stonking Stingray), Canonical has reached a milestone the Linux world has been building toward for a couple of years: the operating system's core command-line utilities are now a fully Rust-based set. The last holdouts — cp, mv, and rm — have moved from the C-based GNU Coreutils to the uutils Rust reimplementation, completing a transition Canonical has been feeding into the distribution since Ubuntu 25.10.² To an end user nothing appears to change; the commands behave as they always have. But the foundation they rest on is now fundamentally different — and the reasons Canonical made the swap say a lot about where systems software is heading.

01What just happened

For decades, the small programs that make up a Unix command line — the tools that list files, copy them, change their permissions, print their contents — have been the GNU Coreutils, written in C and refined over more than thirty years.¹⁰ They are about as foundational as software gets: almost every script, container, and login session on a Linux machine leans on them. Replacing them is not a cosmetic change; it is swapping the engine while the car is running.

That is exactly what Canonical has done. Ubuntu 25.10 (Questing Quokka) shipped the Rust uutils coreutils and the Rust sudo-rs as defaults, making Ubuntu the first major distribution to put memory-safe reimplementations of these tools in front of ordinary users.¹ Ubuntu 26.10 finishes the job by migrating the final three commands that had been left on their GNU versions.² Canonical calls the wider programme "carefully but purposefully oxidising Ubuntu" — oxidation being the Rust community's pun for rewriting software in Rust (iron oxidises into rust).

02Why Canonical is betting on Rust

The case rests almost entirely on memory safety. Languages like C and C++ let a program read or write memory it should not — buffer overflows, use-after-free, invalid writes — and those mistakes are the root cause of a large share of serious security vulnerabilities. Microsoft has reported that roughly 70% of the CVEs it assigns each year are memory-safety issues, and Google has found the same ~70% figure among the serious security bugs in Chromium.⁶ Rust eliminates most of that class of bug at compile time: its ownership and borrow-checking rules make invalid memory access a program that will not build, rather than a crash or exploit at runtime. It is a strong enough argument that US agencies including CISA have urged the industry to move to memory-safe languages for exactly this reason.⁷

Crucially, Rust delivers that safety without giving up the performance an operating system demands. Its zero-cost abstractions let developers write high-level, ergonomic code that compiles down to machine code as fast and as lean as hand-tuned C — no garbage collector, no heavy runtime. Canonical's engineering leadership has framed Rust as the most compelling systems language for the coming decades, on the simple logic that fewer memory bugs mean fewer crashes and a smaller attack surface.¹ For code that runs with high privilege on hundreds of millions of machines, shrinking the attack surface is worth a great deal of engineering effort.

In C, a memory bug is a runtime crash or an exploit. In Rust, the same mistake is usually a compile error — the vulnerability never ships because the program never builds.

03The key replacements: uutils coreutils

The centrepiece is uutils, a cross-platform rewrite of the GNU Coreutils in Rust that aims to be a drop-in replacement.³ Everyday commands — ls, cat, chmod, du, and dozens more — have been reimplemented so that, ideally, you cannot tell the difference from the outside. The three commands that manipulate files most destructively, cp, mv, and rm, were deliberately held back in the 26.04 LTS release because of TOCTOU (time-of-check to time-of-use) bugs — a class of race condition where a file's state changes between the moment a program checks it and the moment it acts, which can be abused. Those issues were resolved upstream (a TOCTOU-resistant copy module landed in a 2026 uutils release), clearing the way for the three commands to ship in 26.10.²

It is worth being precise about what this buys you. The rewrite does not add features you will notice; its payoff is defensive, and it is not free of risk during the transition — new code has new bugs. That is why Canonical is auditing heavily (more on that below) rather than trusting the "Rust is safe" slogan on its own.

04A safer sudo

sudo — the program that lets an ordinary user run a command as root — is one of the most security-sensitive utilities on any system, which makes it a natural early target. Ubuntu 25.10 made sudo-rs the default.⁵ The interesting design choice is that sudo-rs does not try to replicate every quirk of the original C sudo. Rather than chase bug-for-bug compatibility with a large, feature-rich codebase, its developers re-engineered a smaller, functionally safer tool from the ground up, implementing the common paths people actually use and deliberately leaving out rarely-used, historically risky features.⁴

sudo-rs comes out of the Trifecta Tech Foundation's "Privilege Boundary" initiative, which targets exactly the components that handle privilege escalation — the places where a memory bug is most dangerous, because a flaw there can hand an attacker root.⁴ Concentrating the memory-safety effort where the blast radius is largest is a sound way to prioritise.

05Next on the list: ntpd-rs

Canonical is not stopping at coreutils and sudo. The next announced target is time synchronisation: the Rust-based ntpd-rs is slated to become the default Network Time Protocol client by Ubuntu 27.10.² NTP is another quietly critical, network-facing service — a daemon that parses data from the internet is precisely the kind of attack surface where memory safety pays off. The pattern is deliberate: work outward from the most trusted and most exposed components, replacing each with a memory-safe equivalent while keeping behaviour stable.

06Managing the transition and the supply chain

Swapping foundational tools is as much a logistics problem as an engineering one, and Canonical has built process around it:

1. Embedded SBOMs. Since early 2026, Canonical has used the cargo auditable tool to embed a Software Bill of Materials — a precise list of the exact dependency ("crate") versions compiled in — directly into every Rust binary. That makes it far easier to answer "is this machine affected?" when a vulnerability is disclosed in a specific crate version.⁸
2. Deterministic builds via vendoring. Rather than packaging each Rust dependency as its own separate Debian package, Canonical bundles ("vendors") the required dependency code together with the tool, which produces stable, repeatable builds instead of a fragile web of independently-versioned packages.²
3. Independent audits. Canonical commissioned the security firm Zellic to audit the uutils codebase; across the audits Zellic raised more than a hundred issues, dozens of which received CVE identifiers, and Canonical says the large majority have been fixed.² This is the crucial counterweight to the "new code, new bugs" risk of any rewrite.
4. Funding the ecosystem. Canonical backs the effort financially, donating €40,000 a year to the Trifecta Tech Foundation to fund ongoing open-source Rust development, including the upcoming ntpd-rs work.²

07The compatibility grind

The single hardest part of the whole effort is invisible to users: bug-for-bug compatibility. The uutils project targets 100% drop-in compatibility with GNU Coreutils, which means any observable deviation — a different exit code, a slightly different error message, an edge case in how a flag is parsed — is treated as a defect to fix, not an acceptable difference.³ The project measures itself against the official GNU test suite and has been climbing steadily toward full parity, but the last few percent are the hardest: they encode thirty years of accreted, sometimes-undocumented behaviour that real scripts silently depend on.³

This is the grueling, unglamorous work that decides whether the transition is safe. A coreutils command that is 99% compatible sounds excellent until the 1% is the exact flag a critical deployment script relies on. Holding cp, mv, and rm back for an entire LTS cycle over TOCTOU bugs was Canonical choosing that grind over shipping on schedule — the right call for tools that delete data.

08The challenges and the controversy

Not everyone thinks this is progress. The pushback falls into a few camps:

First, the "if it isn't broken" argument. GNU Coreutils has been hardened and optimised for three decades; critics ask whether it is wise to throw out that accumulated reliability and those hard-won optimisations for the promise of memory safety, especially when the specific tools being replaced are mature and already comparatively safe.⁹ A rewrite trades known, battle-tested behaviour for new code that, however careful, has simply had less time in the field.

Second, a licensing objection that matters to the free-software community. GNU Coreutils is licensed under the copyleft GPLv3, which requires anyone who distributes it to share their source. uutils is under the permissive MIT license, which does not — meaning a vendor could bundle it into a closed product without giving anything back. Critics argue that replacing a copyleft cornerstone of the system with a permissively-licensed one quietly erodes the guarantees that made the GNU tools free in the first place.⁹

Third, a philosophical unease: for some, swapping out the GNU userland is a break with the Unix tradition these tools embody, trading decades-old, universally-understood components for something newer on a bet about the future. Even supporters concede that security is not the only motivation — modernising the codebase and attracting new contributors matters too — which is precisely why the debate is more nuanced than "Rust good, C bad."⁹

09Where OcxlyDev lands

Ubuntu's oxidation is a genuinely significant moment: for the first time, a mainstream operating system's core userland is memory-safe by construction rather than by careful hand-auditing. The upside is real and structural — an entire category of vulnerability, the kind responsible for roughly 70% of serious security bugs, is designed out of the most privileged, most-used code on the machine. That is not marketing; it is a different risk profile.

Our take: the sceptics are right that a rewrite is not free — new code carries new bugs, the compatibility tail is brutal, and the licensing shift deserves the scrutiny it is getting. But Canonical is doing this the defensible way — auditing independently, embedding SBOMs, funding the upstream projects, and holding risky commands back until they are ready rather than shipping to a calendar. Memory safety at the foundation is worth pursuing, and doing it carefully, in the open, with the receipts to show for it, is how you earn the right to swap the engine while the car is running. The commands will keep looking the same; that is the point. What changed is everything you cannot see.