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. Acked-by: Tyrel Datwyler <tyreld@xxxxxxxxxxxxx> > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > -Kees >