Linux 7.2 has dropped the last remaining uses of strncpy() from the kernel codebase, closing out a cleanup effort that has been tracked across multiple release cycles.

The motivation is well-documented. The kernel's deprecated-API documentation flags strncpy() explicitly: when the source string is shorter than the destination buffer, the function pads the remainder with NUL bytes — fine — but when the source meets or exceeds the buffer length, it writes no terminating NUL at all. Any subsequent code that treats the destination as a C string then reads into uninitialized or adjacent memory. That class of bug is quiet, context-dependent, and notoriously hard to catch in review.

The kernel's answer has been strscpy(), documented in the core kernel API for 6.4, which always NUL-terminates the destination and returns the number of bytes copied — or -E2BIG if the source was truncated. A companion, strscpy_pad(), covers the subset of callers that genuinely need the old zero-padding behavior. Together they eliminate the ambiguity without forcing every call site to be audited for which failure mode it was silently relying on.

The transition was already well underway by 6.9. The 6.9 deprecated-functions guide lists strncpy() alongside other hazardous interfaces the tree was systematically retiring, and patch series across networking, drivers, filesystems, and arch-specific code had been landing through 6.x with the mechanical substitution. With 7.2, that work is finished.

Finishing this kind of sweep matters more than the individual commits suggest. strncpy() is one of those C standard library functions that looks safe — it takes a length argument, after all — and so it accumulated across decades of kernel contributions by developers who reasonably assumed it was the right tool. The actual hazard only surfaces when callers make assumptions about termination that the function never guarantees. Static analyzers catch some of it; human review catches less. Replacing the function wholesale is the only reliable fix.

The broader context here is that the kernel community has become considerably more systematic about deprecation hygiene over the past several years. The formal deprecated-API document itself is a relatively recent artifact — it codifies what was previously passed on by tribal knowledge — and the pattern of tagging an interface, providing a safe replacement, and then mechanically clearing the tree has now produced results across several hazard classes. strncpy() joins strcpy(), sprintf() into fixed buffers, and several other functions that have been partially or fully retired from new kernel code.

For driver and subsystem developers working against the 7.2 tree, the practical implication is straightforward: new code using strncpy() should expect review pushback, and any out-of-tree code that gets merged will face the same pressure. strscpy() is the default replacement; reach for strscpy_pad() only when the zero-filled tail is a genuine ABI or hardware requirement, not a convenience.

One thing worth flagging: the completion of the removal in mainline does not instantly propagate to the long-term stable branches or to vendor kernels carrying their own patch queues. Downstream trees that have diverged significantly may still carry strncpy() call sites — and the memory-safety argument for cleaning those up is no less valid than it was in mainline. The 7.2 milestone is a clean reference point, not a universal finish line.