Linux 7.2 Finally Executes strncpy After Six Years and 362 Patches

Six Years, 362 Commits, One Dead API

I use Arch, btw — and this week my `pacman -Syu` will eventually pull down a kernel that no longer contains a single call to `strncpy()`. On June 20, 2026, Kees Cook's long-running campaign to purge the string function from the Linux kernel officially crossed the finish line, and the fix landed in the Linux 7.2 merge window. Six years. Three hundred and sixty-two patches. One of C's oldest footguns finally executed inside the kernel that runs 96% of the world's servers.

If you've written C for any length of time, you already know why. `strncpy()` looks like a bounded string copy. It is not. It's a bounded *memory* fill that happens to stop copying when it hits a NUL byte — but it does not guarantee NUL termination on the destination, and it happily zero-pads whatever slack space remains. Two behaviors, one function, both surprising, and both responsible for a decade-plus of CVE reports around information disclosure and unterminated string reads.

Why This Was Actually Hard

The reason this took six years is that `strncpy()` wasn't being used one way — it was being used *five* ways. Different subsystems had adopted the function for semantically distinct operations: NUL-terminated string copies, NUL-terminated copies with explicit padding, fixed-width non-NUL fields, bounded memory copies with padding, and plain known-length `memcpy()` calls masquerading as string operations. Each one had to be identified, understood in context, and replaced with the correct successor.

The kernel now offers five replacements, and each call site had to declare which one it actually meant:

- `strscpy()` — NUL-terminated string destinations (the common case, and what you should reach for by default) - `strscpy_pad()` — NUL-terminated with zero-padding for fixed-width buffers - `strtomem_pad()` — non-NUL-terminated fixed-width fields (ioctl structs, hardware descriptors) - `memcpy_and_pad()` — bounded copies with explicit padding semantics - `memcpy()` — when you actually knew the length all along and were lying to yourself

As the LWN-adjacent commentary put it, this wasn't just a cleanup — it functioned as a codebase-wide audit that forced every site to say what it meant in code instead of relying on developer folklore. Every one of those 362 commits is a place where somebody had to read the surrounding code, figure out the intent, and prove it belonged in exactly one bucket.

The Security Angle Nobody Should Undersell

Here's the thing that gets lost in "legacy API gets deprecated" headlines: this isn't just tidy-up work. The specific memory-error class that `strncpy()` enabled — kernel buffers with sensitive data leaking bytes past an unterminated string boundary into whatever consumed the buffer next — is a memory disclosure primitive. That's the kind of bug that leaks credentials, kernel pointers, or `/dev/kmsg` slop into unprivileged contexts.

By making the function unavailable at the kernel API level, the Linux memory-safety folks converted a best-practice guideline into an enforced policy. You can't accidentally reintroduce a `strncpy()` bug in a new driver anymore, because the symbol won't link. That's the same defensive posture as removing gets() from libc, and it should have happened years ago.

The Bigger Picture: The Kernel Is Getting Serious About C Foot-Guns

The strncpy removal sits in a broader pattern. The kernel has been steadily amputating C footguns: unsized VLAs are gone, flexible array members are enforced, `-Wimplicit-fallthrough` has been mandatory for years, and the KSPP (Kernel Self-Protection Project) has been methodically ratcheting up compiler warnings into hard errors. Rust-for-Linux is another vector on the same problem, but even in pure C, the trend is clear: if the API can be misused catastrophically, it will eventually be removed.

7.2 also brings post-quantum ML-DSA signature support in IMA/EVM, cache-aware CFS scheduling, initial AMDGPU HDMI 2.1 FRL support, and the mod_devicetable.h split that touched over 1,500 files. But the strncpy removal is the one I care about, because it's the one that will stop causing bugs *forever*. New drivers written next year will not have this bug class available to them. That's what real security engineering looks like — not a CVE post-mortem, but an API that no longer exists to abuse.

What This Means for You

If you're running a distro — Arch (btw), Fedora, Debian testing — you'll get 7.2 through your normal upgrade path around mid-August 2026. If you maintain out-of-tree kernel modules, check your code *now*. Any `strncpy()` call in kernel context will fail to build against 7.2. Convert to `strscpy()` by default, and only reach for the padded variants if you actually need the padding semantics.

If you're a userspace developer: relax. `strncpy()` is still in libc. Your janky application code is safe. This is a kernel-internal change, and the C standard isn't changing to accommodate the kernel's higher standards. That's fine — the kernel is a special environment where every buffer overflow is a root exploit waiting to happen, and it should hold itself to a higher bar than random web-facing daemons.

Six years to kill one function. Worth every commit.