Why Linux 7.2 Finally Removed a Risky String Function Hiding in 30 Years of Code

Linux 7.2 has removed the last traces of strncpy() from its codebase — a programming function that, despite looking safe on the surface, has been quietly causing subtle bugs for three decades.

The problem is straightforward. strncpy() is supposed to safely copy text from one place in memory to another by limiting how much it copies. But it has a critical flaw: when the source text is shorter than the destination buffer, it fills the rest with zeros — fine. Yet when the source text is long enough to fill the buffer completely, the function forgets to add a null terminator (the marker that tells the system "the text ends here"). Any code downstream that assumes the text ends properly then keeps reading into random memory. It finds garbage. That garbage corrupts data or crashes the program, and the bug is nearly invisible to catch.

The kernel's deprecated-API documentation has flagged this issue explicitly for years. The Linux team chose a replacement called strscpy(), now documented in the core kernel API, which always adds that closing marker and reports back whether anything was truncated. For the rare cases where old code genuinely needed the zero-padding behavior, there's strscpy_pad(). Together, they leave no ambiguity.

The actual cleanup was a multi-year effort. By version 6.9, the deprecated-functions guide listed strncpy() among other unsafe functions the kernel was systematically retiring, and patches had been landing across the codebase — in networking, device drivers, file systems, and architecture-specific code. By 7.2, the work was done.

The broader context here is that the Linux kernel community has tightened its approach to removing unsafe code. What was once passed along as tribal knowledge — "don't use that function" — is now documented formally, paired with clear replacements, and then removed systematically. strncpy() follows a pattern the community has now applied to strcpy() and sprintf() into fixed buffers, among others.

For developers writing new kernel code against the 7.2 tree, the practical effect is clear: any new code using strncpy() will face pushback during review, and that pressure will apply to code contributed from outside the main kernel project as well. strscpy() is the default; strscpy_pad() is for genuinely special cases where the padding matters for compatibility with hardware or system interfaces, not convenience.

One thing worth noting: removing strncpy() from the official kernel does not automatically clean it up in the long-term stable branches or in vendor kernels that maintain their own patch queues. Downstream versions that have drifted significantly from the main source may still carry strncpy() call sites. The 7.2 release is a clean reference point for the official tree, but not yet a finish line everywhere else.

For someone working on kernel code or driver development, the takeaway is straightforward: the kernel community has chosen its path, and strscpy() is now the only acceptable answer for string copying. Understanding that function and when to reach for its variants will only become more common as the ecosystem catches up.