Re: [PATCH] scsi: message: fusion: replace deprecated strncpy with strscpy

[Kees Cook <keescook@chromium.org>]

On Wed, Sep 27, 2023 at 04:43:08AM +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.
> 
> The only caller of mptsas_exp_repmanufacture_info() is
> mptsas_probe_one_phy() which can allocate rphy in either
> sas_end_device_alloc() or sas_expander_alloc(). Both of which
> zero-allocate:
> |       rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
> ... this is supplied to mptsas_exp_repmanufacture_info() as edev meaning
> that no future NUL-padding of edev members is needed.
> 
> 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.
> 
> Note that while `strscpy(dest, src, sizeof(dest))` is more idiomatic
> strscpy usage, we should keep `SAS_EXPANDER...LEN` for length arguments
> since changing these to sizeof would mean we are getting buffers one
> character larger than expected due to the declaration for these members:
> |       char   vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
> |       char   product_id[SAS_EXPANDER_PRODUCT_ID_LEN+1];
> |       char   product_rev[SAS_EXPANDER_PRODUCT_REV_LEN+1];
> |       char   component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN+1];
> ... and simply removing the "+1" in conjunction with using sizeof() may
> not work as other code may rely on this adjusted buffer length for
> sas_expander_device members.

I don't agree with this assessment: without the +1, moving to strscpy()
could lead to early truncation. I would change all of them to use
sizeof(), so that %NUL termination will happen at the right place when a
maxmimally sized string source is used.

i.e. for this:

	dst[FOO + 1] = { };

	strncpy(dst, src, FOO);

we will copy at most FOO bytes into dst, leaving dst[FOO] as '\0'.

If we replace it with:

	strscpy(dst, src, FOO);

Then we'll copy at most FOO-1 bytes into dst, setting dst[FOO - 1] = '\0';

So, these need to be adjusted to use sizeof(dst)...

-Kees

> 
> 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@vger.kernel.org
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Justin Stitt <justinstitt@google.com>
> ---
> Note: build-tested only.
> 
> Note: similar to drivers/scsi/mpi3mr/mpi3mr_transport.c +212 which uses
> strscpy
> ---
>  drivers/message/fusion/mptsas.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 86f16f3ea478..1dc225701a50 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2964,15 +2964,15 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
>  			goto out_free;
>  
>  		manufacture_reply = data_out + sizeof(struct rep_manu_request);
> -		strncpy(edev->vendor_id, manufacture_reply->vendor_id,
> +		strscpy(edev->vendor_id, manufacture_reply->vendor_id,
>  			SAS_EXPANDER_VENDOR_ID_LEN);
> -		strncpy(edev->product_id, manufacture_reply->product_id,
> +		strscpy(edev->product_id, manufacture_reply->product_id,
>  			SAS_EXPANDER_PRODUCT_ID_LEN);
> -		strncpy(edev->product_rev, manufacture_reply->product_rev,
> +		strscpy(edev->product_rev, manufacture_reply->product_rev,
>  			SAS_EXPANDER_PRODUCT_REV_LEN);
>  		edev->level = manufacture_reply->sas_format;
>  		if (manufacture_reply->sas_format) {
> -			strncpy(edev->component_vendor_id,
> +			strscpy(edev->component_vendor_id,
>  				manufacture_reply->component_vendor_id,
>  				SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN);
>  			tmp = (u8 *)&manufacture_reply->component_id;
> 
> ---
> base-commit: 6465e260f48790807eef06b583b38ca9789b6072
> change-id: 20230927-strncpy-drivers-message-fusion-mptsas-c-f22d5a4082e2
> 
> Best regards,
> --
> Justin Stitt <justinstitt@google.com>
> 

-- 
Kees Cook