On Dec 24, 2007 4:40 AM, Rico Secada <[EMAIL PROTECTED]> wrote: > Linus agreed that following OpenBSD's lead was the right way forward, > and strlcpy() is in his BitKeeper repository, waiting for 2.5.71. There > has also been a flurry of activity to convert kernel code over to the > new function. By the time 2.6.0 comes out, strncpy() may no longer have > a place in the Linux kernel.
We are nearly in 2008, 2.6.24 is on its way to the release, and strncpy bugs still appear in the Linux kernel. I just stumbled upon this, it's a commit from yesterday in Linus' tree: From: Eric Sandeen <[EMAIL PROTECTED]> Date: Sat, 22 Dec 2007 22:03:24 +0000 (-0800) Subject: ecryptfs: fix string overflow on long cipher names X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=b88629060b03adc58639f818fe0968bf5fe81b5d ecryptfs: fix string overflow on long cipher names Passing a cipher name > 32 chars on mount results in an overflow when the cipher name is printed, because the last character in the struct ecryptfs_key_tfm's cipher_name string was never zeroed. Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]> Acked-by: Michael Halcrow <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> --- diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c index bbed2fd..67e8b16 100644 --- a/fs/ecryptfs/crypto.c +++ b/fs/ecryptfs/crypto.c @@ -1847,6 +1847,7 @@ ecryptfs_add_new_key_tfm(struct ecryptfs_key_tfm **key_tfm, char *cipher_name, mutex_init(&tmp_tfm->key_tfm_mutex); strncpy(tmp_tfm->cipher_name, cipher_name, ECRYPTFS_MAX_CIPHER_NAME_SIZE); + tmp_tfm->cipher_name[ECRYPTFS_MAX_CIPHER_NAME_SIZE] = '\0'; tmp_tfm->key_size = key_size; rc = ecryptfs_process_key_cipher(&tmp_tfm->key_tfm, tmp_tfm->cipher_name, -- Pierre Riteau
