[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202310021041.FA60C9812@keescook>
Date: Mon, 2 Oct 2023 10:41:48 -0700
From: Kees Cook <keescook@...omium.org>
To: Justin Stitt <justinstitt@...gle.com>
Cc: Sathya Prakash <sathya.prakash@...adcom.com>,
Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
Suganath Prabu Subramani
<suganath-prabu.subramani@...adcom.com>,
MPT-FusionLinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] scsi: message: fusion: replace deprecated strncpy with
strscpy_pad
On Wed, Sep 27, 2023 at 04:06:09AM +0000, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> Since all these structs are copied out to userspace let's keep them
> NUL-padded by using `strscpy_pad` which guarantees NUL-termination of
> the destination buffer while also providing the NUL-padding behavior
> that strncpy has.
>
> Let's also opt to use the more idiomatic strscpy usage of:
> `dest, src, sizeof(dest)` in cases where the compiler can determine the
> size of the destination buffer. Do this for all cases of strscpy...() in
> this file.
>
> To be abundantly sure we don't leak stack data out to user space let's
> also change a strscpy to strscpy_pad. This strscpy was introduced in
> Commit dbe37c71d1246ec2 ("scsi: message: fusion: Replace all
> non-returning strlcpy() with strscpy()")
>
> Note that since we are creating these structs with a copy_from_user()
> and modifying fields and then copying back out to the user it is
> probably OK not to explicitly NUL-pad everything as any data leak is
> probably just data from the user themselves. If this is too eager, let's
> opt for `strscpy` which is still in the spirit of removing deprecated
> strncpy usage treewide.
>
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-hardening@...r.kernel.org
> Cc: Kees Cook <keescook@...omium.org>
> Signed-off-by: Justin Stitt <justinstitt@...gle.com>
Agreed -- this looks more robust and readable. Thanks!
Reviewed-by: Kees Cook <keescook@...omium.org>
--
Kees Cook
Powered by blists - more mailing lists