Linux Just Fixed a Hidden Memory Problem That's Been Around for Decades

Linux 7.2 has removed the last uses of an older copying tool called strncpy() from its core code. This closes out a cleanup effort that took several years across multiple software versions.

To understand why this matters, think of strncpy() as a tool for copying text. It's been around since the early days of the C programming language — the basic building block of Unix and Linux — and for decades, programmers used it because it looked safe. It takes a length argument, which is supposed to protect against accidents. But it had a hidden problem.

The Problem

The issue is subtle. When strncpy() copies a piece of text and the source text is shorter than the space available, it fills the leftover space with empty bytes — fine. But when the source text is as long as or longer than the available space, the function doesn't mark the end of the copied text. In C, programs need a special marker — a NUL terminator — to know where a piece of text ends. Without it, programs keep reading into whatever happens to be in the nearby memory, grabbing garbage data or sensitive information.

This kind of bug is quiet. It doesn't crash the system immediately. Whether it causes trouble depends on what happens next — on what code runs after the copy, and what assumptions it makes. That makes it almost invisible to human code reviewers.

The Solution

The Linux kernel community built a replacement called strscpy(). This new tool always adds the proper end-of-text marker. It also tells the calling code whether the copy was successful or whether the source was too long for the buffer — instead of silently allowing a dangerous situation. For the rare cases where code genuinely needs the old zero-padding behavior, there's strscpy_pad(). Together, these two tools eliminate the ambiguity that made strncpy() hazardous.

The transition started several years ago. In version 6.9, the kernel's maintainers listed strncpy() alongside other unsafe functions they were systematically retiring, and patches began landing across different parts of the code — networking, device drivers, file systems, and processor-specific code. Version 7.2 marks the point where that work is finally complete.

Why This Matters

Finishing a cleanup like this is important, even if it sounds like a minor technical task. strncpy() accumulated across decades of kernel contributions because it looked reasonable. The actual danger only shows up when code makes assumptions about how text is marked that the function never promised to satisfy. Tools that scan code automatically catch some of these bugs; human reviewers catch fewer. Replacing the function entirely was the only truly reliable fix.

The broader context here is that the Linux kernel community has become more systematic about weeding out unsafe tools over the past several years. The kernel now maintains a formal list of deprecated functions — functions that are being phased out — and when the community identifies a hazardous tool, they pick a safer replacement, switch all existing code over, and then enforce the new standard going forward. strncpy() joins other unsafe functions like strcpy() that have already been retired from new kernel code.

For people writing new code for Linux 7.2 and later, the practical reality is straightforward: using strncpy() will trigger pushback from experienced reviewers, and code that does use it will need to be rewritten. strscpy() is the default choice; strscpy_pad() should only be used when the zero-filled padding is truly required by hardware or backward compatibility, not as a convenience.

One detail worth acknowledging: completing the removal in the main Linux codebase doesn't instantly change long-term stable versions or custom kernels that companies build and maintain separately. Some of those downstream branches may still contain code that uses strncpy(). The memory-safety argument for cleaning those up is just as valid as it was for the main kernel. Version 7.2 is a clear reference point, not a universal finish line.