Linux Kernel Removes strncpy After Six Years and 362 Patches

Security · June 22, 2026

Linux Kernel Removes strncpy After Six Years and 362 Patches

A cleanup campaign that most developers had stopped expecting to end closed out last Friday: the complete removal of a 50-year-old C function the kernel’s own documentation called “actively dangerous.”

On June 20, 2026, a single merge into the Linux 7.2 development tree ended a six-year effort that had required 362 individual commits and the hands-on involvement of 70 contributors: every last call to strncpy() was removed from the Linux kernel source tree, and the function’s implementation itself — including per-CPU-architecture optimised versions — was deleted along with it.

The merge was confirmed by Phoronix and acknowledged by Kees Cook, the Google engineer who leads the Kernel Self Protection Project and who personally handled the final six remaining instances. Cook summed it up plainly: “We can remove strncpy() from the Linux kernel finally! Over the last 6 years working on this, there were 362 commits by 70 contributors.”

Why strncpy Was a Problem

strncpy was designed in the early Unix era for copying strings into fixed-width record fields — a context where zero-padding the remainder of a buffer was intentional. Decades later, developers adopted it as a general-purpose “safe” alternative to strcpy, and that mismatch between its design intent and actual use created two recurring bug patterns.

The first and more serious issue concerns NUL termination. When the source string is exactly as long as, or longer than, the specified byte limit n, strncpy copies n bytes and stops — without appending a terminating '\0' character. Any subsequent code that treats the destination buffer as a C string will read past its boundary into adjacent kernel memory, potentially disclosing sensitive data. The Linux kernel’s own documentation labelled this behaviour a “persistent source of bugs.” The second issue is performance: when the source is shorter than the destination, strncpy zero-fills every remaining byte — writing hundreds or thousands of unnecessary bytes on every call.

Why Automated Replacement Was Not Possible

A naive text substitution of every strncpy call with a single safer function would have introduced new bugs. Each call site had to be read and understood individually, because different uses relied on different behaviours:

Some truly were simple string copies and could become strscpy() directly. Others intentionally combined buffer clearing with a partial copy, relying on the zero-padding side effect. A third category interacted with fixed-width binary fields in network or file-system structures where no NUL terminator was ever expected. The Kernel Self Protection Project used Coccinelle — the Linux community’s semantic patching framework — to identify patterns safe for automated substitution, but unusual call sites required manual inspection and, in many cases, a rewrite of surrounding logic.

That is why the effort took six years rather than a single merge: it was, in effect, a codebase-wide audit that forced every string-copy operation in the kernel to declare its actual intent in code.

The Replacement Functions

The kernel did not settle on a single drop-in replacement. Instead, five purpose-named functions now cover the distinct use cases that strncpy had previously blurred together:

The function names themselves encode the intent of each operation — a deliberate design choice that makes misuse harder for future contributors to introduce accidentally.

What the Removal Enforces Going Forward

Removing the function’s implementation from the source tree means that a future kernel developer cannot reach for strncpy even if they want to. What was previously a best-practice recommendation has become an enforced policy: the compiler will reject any new code that attempts to call it. The 362-commit audit simultaneously made the kernel’s string-handling semantics explicit where they were previously implicit, giving future maintainers clearer signal about what every copy operation actually does.

A Milestone in a Longer Security Shift

The strncpy removal is the most visible recent example of a broader pattern in kernel development: retiring APIs whose names imply safety while their behaviour undermines it. Similar campaigns are already underway against sprintf (which performs no bounds checking and is being steadily replaced by snprintf) and against strcat/strncat, which carry comparable termination ambiguities.

Running in parallel is the kernel’s adoption of Rust. Since kernel 6.1, Rust has been an officially supported implementation language; its ownership model and borrow checker prevent entire classes of memory errors at compile time, making debates about strncpy versus strscpy structurally impossible in Rust-authored subsystems. Rust currently represents a small fraction of the 30-million-line tree, but the direction of travel is clear: the kernel community is moving from relying on developer discipline to encoding safety guarantees in the toolchain itself.

The strncpy removal does not affect user-space applications. Standard C library implementations in Linux distributions continue to provide the function for programs running on top of the kernel; existing software compiles and runs normally. Only code that targets the kernel itself is affected.