After Six Years Of Work and Over 360 Patches, Linux 7.2 Finally Removes Bug-Prone strncpy (techtimes.com) 36
Tech Times reports:
Linux 7.2's merge window closed out a cleanup campaign on Friday that most kernel developers had stopped expecting to see end: the complete removal of strncpy(), a C string-copy function that the kernel's own documentation labels "actively dangerous," from every subsystem, driver, and architecture-specific file in the kernel source tree.
The merge landed June 20, 2026. After around 362 commits spread across six years of incremental work, no call site using the function remained, and the function itself — including the last per-CPU-architecture optimized implementations — was struck from the source. The removal matters beyond housekeeping. strncpy() is a persistent source of a specific class of memory error: kernel buffers that contain sensitive data can leak bytes past an unterminated string boundary, a pattern that enables memory disclosure vulnerabilities. Eliminating the function from the tree removes that entire class from the kernel's attack surface — and, critically, makes strncpy() unavailable to any future contributor, turning a best-practice suggestion into an enforced policy.
Phoronix notes it's replaced by five different functions: In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies.
"The reason five functions were needed," explains Tech Times, "is that different parts of the kernel were using strncpy() for five semantically distinct memory operations — each with a different intent, different termination requirement, and different padding behavior. " The original function obscured all of those differences under a single ambiguous name. The 362-commit campaign to replace it was, in effect, a codebase-wide audit that forced every call site to declare its actual intent in code That is an engineering outcome with lasting value: the kernel's string-handling semantics are now explicit where they were previously implicit, and future maintainers can read a function name and understand what a copy operation actually does.
The merge landed June 20, 2026. After around 362 commits spread across six years of incremental work, no call site using the function remained, and the function itself — including the last per-CPU-architecture optimized implementations — was struck from the source. The removal matters beyond housekeeping. strncpy() is a persistent source of a specific class of memory error: kernel buffers that contain sensitive data can leak bytes past an unterminated string boundary, a pattern that enables memory disclosure vulnerabilities. Eliminating the function from the tree removes that entire class from the kernel's attack surface — and, critically, makes strncpy() unavailable to any future contributor, turning a best-practice suggestion into an enforced policy.
Phoronix notes it's replaced by five different functions: In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies.
"The reason five functions were needed," explains Tech Times, "is that different parts of the kernel were using strncpy() for five semantically distinct memory operations — each with a different intent, different termination requirement, and different padding behavior. " The original function obscured all of those differences under a single ambiguous name. The 362-commit campaign to replace it was, in effect, a codebase-wide audit that forced every call site to declare its actual intent in code That is an engineering outcome with lasting value: the kernel's string-handling semantics are now explicit where they were previously implicit, and future maintainers can read a function name and understand what a copy operation actually does.
C (and here are somemore chars to satisfy the bot) (Score:3)
One of the annoyances of C: using a string function for operations that have nothing to do with strings. One of the many reasons I used to hate trying to understand other people's C code.
Re:C (and here are somemore chars to satisfy the b (Score:5, Informative)
Why would you do that? If you're using it for non-strings, you'd never have used strncpy, you'd have used memcpy. Which is the same thing without the null termination rules of strncpy. You'd never use the str versions unless actually working on strings.
Re: C (and here are somemore chars to satisfy the (Score:4, Interesting)
Re: (Score:3)
It is surprising how often I encounter strings with NULs in the middle. Bytes have 256 different values, and sooner or later someone wants to transmit all 256 values in what was an ascii text-based conversation. HTTP is a good example. The conversation starts as a normal group of strings, until the header says "Content-Length:" and a bunch of binary data follows later.
Another issue in C is that strings are used for both immutable strings and for string buffers. Java makes it clear that string buffer is
Re: (Score:2)
Ah, if only we could employ perfect programmers who follow the proper rules all the time and consistently, then we would all be safe. And if I had a pink unicorn, then I'd be rich.
Re: (Score:3)
C doesn't have strings, but sometimes people like to have some bytes with a 0 on the end. Some of the memxxx() functions are useful with C's fake strings. For example, memchr() is good for when you have a null-terminated string but it also some upper bounds. And stuff like strncpy() doesn't appear to have anything at all to do with null terminated strings, and is grossly misnamed.
Re:C (and here are somemore chars to satisfy the b (Score:5, Interesting)
strncpy() copies a string to another location stopping when it reaches a NUL or the end of the buffer.
The problem is the second case doesn't NUL terminate the string so you either have to make the buffer one smaller and terminate always or terminate always. Or try to handle it. The other problem is 'n' is unintuitive - it's the size of the buffer in characters. Easy peasy with 8-bit chars, not so much for Unicode strings. (UTF-16...)
I've personally be more of a fan of the BSD "l" versions - strlcpy and strlcat - both take the size of the target buffer in bytes - so a sizeof() is the proper way to use it, and both properly NUL terminate the string. strlcat has the added benefit that it computes the size it needs to copy based on the existing length of the string, so you can use strlcat() to concatenate a bunch of strings without computing the remaining buffer sizes (as you would in strncat). Luckily the BSD versions are in libbsd because they aren't in Glibc. Much nicer and much easier to use functions.
Re: (Score:2)
in embedded use I ban strncpy and offer a strlcat version.
Re: (Score:2)
strncpy() copies a string to another location stopping when it reaches a NUL or the end of the buffer.
And, as stated, NUL terminates the result in some, but not all cases.
It breaks the rule of UNIX utilities: Do one simple thing and do it well.
Re: (Score:2)
If you read the articles, you will see that the Linux kernel has retired strlcpy() 2 years ago. strlcpy() was introduced into Linux kernel code later than strncpy(), thus get eliminated more easily.
The major issue of strlcpy() is, it needs to check the source string length, then decide whether to do the string copy or not. So in effect the computer needs to parse the source string twice unnecessarily, and introduces a timing gap, making the function not thread safe.
strscpy() is thread safe because it a
Re: (Score:2)
The major issue of strlcpy() is, it needs to check the source string length, then decide whether to do the string copy or not. So in effect the computer needs to parse the source string twice unnecessarily, and introduces a timing gap, making the function not thread safe.
strscpy() is thread safe because it always tries to copy the source string regardless it will truncate or not. Thus a change of content of source string in the middle of strscpy() operation is not going to cause any undefined behaviour. The implementation can be thread safe.
What is being described is GIGO not thread safety.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I expect SystemD was originally created because someone looked at Apple's LaunchD and decided they wanted a GPL-compatible alternative
This kind of thing should be encapsulated in a macro or function so you don't make mistakes.
Using the raw stdlib string library will cause security problems. These can be avoided 100% by using custom string functions.
Re: (Score:2)
UTF-8 was a mistake. I get that they wanted to make string handling with existing code as painless as possible, and for most Latin derived languages a 32 bit char is approaching 75% wasted space, but the issues introduced by UTF-8 are far worse. UTF-16 doesn't have enough code points. You could argue for 24 bit.
Re: C (and here are somemore chars to satisfy the (Score:2)
I rarely use C. I generally use Typescript or Python these days.
But it is a genuine love I have of C, that it's so close to the hardware, and so powerful because of that, second only to raw assembler. (I tend to "visualise" how computers work through C).
But it's also so dangerous and easy to use wrong.
Re: (Score:3)
Really? I don't recall ever seeing that. memcpy() is generally used in those cases.
Re: (Score:3)
C (and here are somemore chars to satisfy the b
I wonder where the rest of the characters following 'b' got copied.
Re: (Score:3)
The real problem with C is that it doesn't have any built-in support for strings. Everyone is forced to fake it with char-arrays, which aren't quite the same thing and require very careful handling. The problem with that is, everyone has their off days, and so everyone who does string-handling in C eventually ends up shipping string-related bugs that introduce security problems.
strncpy never made sense (Score:4, Insightful)
strncpy() should always have null terminated on truncation. I can't think of a single time i've ever used it where i didn't want it to terminate
Re: strncpy never made sense (Score:2)
Agreed. It was a badly design function from the get go - yeah let's have a function that copies a string and nul terminates except when it doesnt. Genius.
Re: strncpy never made sense (Score:4, Insightful)
strncpy() was not intended for null-terminated strings at all. It should have been named copy_null_padded_buffer(). Then its operation would have made sense to almost anyone. People wouldn't have minded the longer name much either, because hardly anybody uses null-padded buffers in modern software.
Note that a null-padded buffer that is completely full doesn't have any nulls in it at all. That's why strncpy() doesn't necessarily add a null termination. It also fills the entire destination buffer with nulls after the end of a short copy, which can be very inefficient when used with null-terminated strings.
TL;DR: don't use strncpy(). It doesn't do what anybody thinks it does.
Re: (Score:1)
Go Janitors! (Score:5, Interesting)
I see so many names in the commit logs, but some standouts include: Blum, Cook, Torvalds, Solodai, Tyragu, Stitt, Bergmann, Wysocki, Panda, de Mello, and no doubt some I missed who have a large number of commits fixing this problem.
Thank to all who undertook this Herculean chore!
Re: (Score:2)
Yeah, you've got to have some respect for a load of people who've made difficult, error prone changes across a load of code they probably didn't write and don't know super well - not to make anything any different, but just to avoid a possible problem in the future.
strcpy (Score:3, Funny)
They took away my strncpy? No problem, I'll use strcpy instead.
Why C is dangerous (Score:1)
I'm sure I'll get flamed, but this is why C (and other languages that don't provide mechanisms to BOUND the length of a string) are actively dangerous in The Real World. Look at the massive effort and time to mitigate this VERY COMMON AND WELL UNDERSTOOD vulnerability.
Re:Why C is dangerous (Score:4, Informative)
You can use a safe string type in C as many people do and use other language features to get bounds checking in C.
For example: https://godbolt.org/z/4Tn8jaGM... [godbolt.org]
It is not clear to me why people do not use this more, but I think the constant misinformation that this is not possible in C is not helping.
Re: (Score:3)
But the evidence is clear from this incident: What people "can do" and what people "actually do" are VERY different things.
Re: (Score:2)
Re: (Score:2)