On Thu, Jan 18, 2024 at 12:21:04PM -0800, Tyrel Datwyler wrote: > On 12/12/23 13:23, Kees Cook wrote: > > On Tue, Dec 12, 2023 at 01:20:20AM +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. > >> > >> We don't need the NUL-padding behavior that strncpy() provides as vscsi > >> is NUL-allocated in ibmvscsis_probe() which proceeds to call > >> ibmvscsis_adapter_info(): > >> | vscsi = kzalloc(sizeof(*vscsi), GFP_KERNEL); > >> > >> ibmvscsis_probe() -> ibmvscsis_handle_crq() -> ibmvscsis_parse_command() > >> -> ibmvscsis_mad() -> ibmvscsis_process_mad() -> ibmvscsis_adapter_info() > >> > >> Following the same idea, `partition_name` is defiend as: > >> | static char partition_name[PARTITION_NAMELEN] = "UNKNOWN"; > >> ... which is NUL-padded already, meaning strscpy() is the best option. > >> > >> Considering the above, a suitable replacement is `strscpy` [2] due to > >> the fact that it guarantees NUL-termination on the destination buffer > >> without unnecessarily NUL-padding. > >> > >> However, for cap->name and info let's use strscpy_pad as they are > >> allocated via dma_alloc_coherent(): > >> | cap = dma_alloc_coherent(&vscsi->dma_dev->dev, olen, &token, > >> | GFP_ATOMIC); > >> & > >> | info = dma_alloc_coherent(&vscsi->dma_dev->dev, sizeof(*info), &token, > >> | GFP_ATOMIC); > >> > >> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > >> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > >> Link: https://github.com/KSPP/linux/issues/90 > >> Cc: linux-hardening@xxxxxxxxxxxxxxx > >> Signed-off-by: Justin Stitt <justinstitt@xxxxxxxxxx> > > > > This looks good to me. The only question that I haven't seen an answer > > to from the maintainers is whether this is a __nonstring or not. It > > really looks like it should be a C String, so with that assumption: > > To reaffirm the assumption, as I mentioned in my response to v1 these are > intended to be handled as C strings. Great; thanks! Are you taking this, or should I carry it in the hardening tree? -Kees > > Acked-by: Tyrel Datwyler <tyreld@xxxxxxxxxxxxx> > > > > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > > > -Kees > > > -- Kees Cook
