Please revert the following item from Ben Collins' "drivers/* strlcpy
conversions" patch dated 2003-May-26.
The strlcpy function requires a zero-terminated string, which is not a
valid assumption for the code in question. I suggest that Ben review
all such modifications he made to the kernel for similar errors. It's
quite annoying to have someone add bugs to your driver while you're not
looking. Either notify the maintainer of your patch or don't make mistakes.
Another gripe I have is that bitkeeper user "bcollins" does not have a
valid email address.
-John Belmonte
Item to be REVERTED:
--- 1.9/drivers/acpi/toshiba_acpi.c Mon May 19 10:57:16 2003
+++ 1.10/drivers/acpi/toshiba_acpi.c Sun May 25 17:00:00 2003
@@ -108,8 +108,7 @@
int result;
char* str2 = kmalloc(n + 1, GFP_KERNEL);
if (str2 == 0) return 0;
- strncpy(str2, str, n);
- str2[n] = 0;
+ strlcpy(str2, str, n);
va_start(args, format);
result = vsscanf(str2, format, args);
va_end(args);
References:
http://www.ussg.iu.edu/hypermail/linux/kernel/0305.3/0267.html
http://linux-acpi.bkbits.net:8080/linux-acpi/diffs/drivers/acpi/[email protected]?nav=index.html|src/|src/drivers|src/drivers/acpi|hist/drivers/acpi/toshiba_acpi.c
--
http:// if l .o /
On Fri, Jul 25, 2003 at 10:46:38AM -0400, John Belmonte wrote:
> Please revert the following item from Ben Collins' "drivers/* strlcpy
> conversions" patch dated 2003-May-26.
>
> The strlcpy function requires a zero-terminated string, which is not a
> valid assumption for the code in question. I suggest that Ben review
> all such modifications he made to the kernel for similar errors. It's
> quite annoying to have someone add bugs to your driver while you're not
> looking. Either notify the maintainer of your patch or don't make mistakes.
Nope. Kernel strlcpy implementation is crap and I do not believe that there
is single place in the kernel which can live with current implementation.
Take a look at ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/strlcpy.c
or at http://www.courtesan.com/todd/papers/strlcpy.html - it copies
at most size-1 characters. Nothing about characters beyond specified size
in the article.
Kernel should use strnlen() to get string length, if coding loop like
OpenBSD does is unacceptable.
Best regards,
Petr Vandrovec
On Fri, Jul 25, 2003 at 06:15:10PM +0200, Petr Vandrovec wrote:
> Nope. Kernel strlcpy implementation is crap and I do not believe that there
> is single place in the kernel which can live with current implementation.
>
> Take a look at ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/strlcpy.c
> or at http://www.courtesan.com/todd/papers/strlcpy.html - it copies
> at most size-1 characters. Nothing about characters beyond specified size
> in the article.
>
> Kernel should use strnlen() to get string length, if coding loop like
> OpenBSD does is unacceptable.
strlcpy is for strings, not for character arrays.
The *BSD version accesses the source past the size-1 characters that are copied:
while (*s++)
;
Thus, replacing strncpy (used to copy character arrays, possibly not 0-terminated)
by strlcpy is wrong.
In message: <[email protected]>
Matthew Wilcox <[email protected]> writes:
: On Fri, Jul 25, 2003 at 06:57:09PM +0200, Andries Brouwer wrote:
: > strlcpy is for strings, not for character arrays.
: > The *BSD version accesses the source past the size-1 characters
: > that are copied:
: > while (*s++)
: > ;
: > Thus, replacing strncpy (used to copy character arrays, possibly
: > not 0-terminated) by strlcpy is wrong.
Ah, that's to get the silly return value correct :-(.
Warner
On Fri, Jul 25, 2003 at 06:57:09PM +0200, Andries Brouwer wrote:
> strlcpy is for strings, not for character arrays.
> The *BSD version accesses the source past the size-1 characters that are copied:
> while (*s++)
> ;
> Thus, replacing strncpy (used to copy character arrays, possibly not 0-terminated)
> by strlcpy is wrong.
But using strncpy() is _also_ wrong because of its NUL-padding behaviour.
There's really four different situations and strncpy is only suitable
for one of them:
a) Copy at most n bytes of a string to another string (strlcpy)
b) Copy at most n bytes from a character array into a string (strncat?)
c) Copy at most n bytes from a string to a character array that will
be returned to user space (strncpy)
d) Copy n bytes from one character array to another (memcpy)
stpcpy is another interesting variant on the awful strcpy, but we'd need
a stpncpy too. strncat is a little dubious for case (b) since you need
to initialise the dest with a NUL in the first byte.
C's string handling sucks, and everybody knows it. Making strings a first
class object may be a cure worse than the disease (for the intended use
of C; for scripting languages it makes perfect sense).
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk