[Top] [All Lists]

Re: [PATCH 2.6]: IPv6: strcpy -> strlcpy

To: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 2.6]: IPv6: strcpy -> strlcpy
From: Felipe Alfaro Solana <felipe_alfaro@xxxxxxxxxxxxx>
Date: Fri, 28 Nov 2003 00:03:29 +0100
Cc: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" <yoshfuji@xxxxxxxxxxxxxx>, davem@xxxxxxxxxx, Linux Kernel Mailinglist <linux-kernel@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20031127221928.F25015@xxxxxxxxxxxxxxxxxxxxxx>
References: <1069934643.2393.0.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <20031127.210953.116254624.yoshfuji@xxxxxxxxxxxxxx> <20031127194602.A25015@xxxxxxxxxxxxxxxxxxxxxx> <20031128.045413.133305490.yoshfuji@xxxxxxxxxxxxxx> <20031127200041.B25015@xxxxxxxxxxxxxxxxxxxxxx> <1069970770.2138.10.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <20031127221928.F25015@xxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 2003-11-27 at 23:19, Russell King wrote:

> You misunderstand me.  Consider the difference between:

OK, it's perfectly clear now :-)

> Note my final sentence there.  Consider the following:
>       char foo[256];
>       strlcpy(foo, "hello", sizeof(foo);
>       copy_to_user(uptr, foo, sizeof(foo));
> That ends up writing uninitialised kernel data to (unprivileged) user
> space.  So would strcpy() used in that situation.
> strncpy() on the other hand, will zero the rest of the buffer (on x86
> at least) but you'll have to manually ensure that there is a terminator
> on the end.  Or, you use strlcpy but memset the entire space you're
> copying the string into beforehand, which could be wasteful.
> Note: we should really fix the generic strncpy() - there are places in
> the kernel source which rely on the x86 strncpy() behaviour today (eg,
> binfmt_*.c core file generation.)

So, as I see:

1. We should fix strncpy()
2. I should replace strlcpy() with strncpy() in my patches.

<Prev in Thread] Current Thread [Next in Thread>