Sound updating, security of strlcpy and a question on pci v unload
Quoted 16 lines · Mitchell Blank Jr
Quoted 5 lines · Mikulas Patocka
What's the difference there? strlcpy always creates null-terminated string, strncpy doesn't. strncpy in kernel (unlike user strncpy) does not pad the whole destination buffer with zeros (see comment and implementation in
lib/string.c), so I don't see any point why strncpy should be more secure.Not only that, I think the point is usually moot anyway. If you're filling in a structure to pass to userspace like:
struct whatever foo;
strncpy(foo.name, "My Driver", sizeof(foo.name)); foo.count = 1;
[...]
Quoted 4 lines
then you're STILL probably at risk of data leakage if "struct whatever" requires padding on any architecture. The real fix is to make sure that "foo" is explicitly zero'ed out first. Then strlcpy-vs-strncpy becomes a non-issue.
gcc -Wpadding ...
If the compiler has to add padding, then the programmer most likely messed up. The warning catches stupidity. Necessary padding can be explicit.