linux-kernel - Re: [PATCH] scsi: elx: sli4: Replace deprecated strncpy() with strscpy()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202504071126.37117C5D@keescook>
Date: Mon, 7 Apr 2025 11:28:32 -0700
From: Kees Cook <kees@...nel.org>
To: Thorsten Blum <thorsten.blum@...ux.dev>
Cc: James Smart <james.smart@...adcom.com>,
	Ram Vegesna <ram.vegesna@...adcom.com>,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	linux-hardening@...r.kernel.org, linux-scsi@...r.kernel.org,
	target-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: elx: sli4: Replace deprecated strncpy() with
 strscpy()

On Wed, Feb 26, 2025 at 07:55:26PM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers; use
> strscpy() instead.
> 
> Compile-tested only.
> 
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-hardening@...r.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@...ux.dev>
> ---
>  drivers/scsi/elx/libefc_sli/sli4.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/elx/libefc_sli/sli4.c b/drivers/scsi/elx/libefc_sli/sli4.c
> index 5e7fb110bc3f..d9a231fc0e0d 100644
> --- a/drivers/scsi/elx/libefc_sli/sli4.c
> +++ b/drivers/scsi/elx/libefc_sli/sli4.c
> @@ -3804,7 +3804,7 @@ sli_cmd_common_write_object(struct sli4 *sli4, void *buf, u16 noc,
>  	wr_obj->desired_write_len_dword = cpu_to_le32(dwflags);
>  
>  	wr_obj->write_offset = cpu_to_le32(offset);
> -	strncpy(wr_obj->object_name, obj_name, sizeof(wr_obj->object_name) - 1);
> +	strscpy(wr_obj->object_name, obj_name);

Standard question for these kinds of conversions: Why is it safe that
this is not NUL padded? I haven't found where this buffer is being
zeroed out, but it probably is (given the "- 1" on the length), but
without run-time testing, this needs much more careful analysis.

-Kees

>  	wr_obj->host_buffer_descriptor_count = cpu_to_le32(1);
>  
>  	bde = (struct sli4_bde *)wr_obj->host_buffer_descriptor;
> @@ -3833,7 +3833,7 @@ sli_cmd_common_delete_object(struct sli4 *sli4, void *buf, char *obj_name)
>  			 SLI4_SUBSYSTEM_COMMON, CMD_V0,
>  			 SLI4_RQST_PYLD_LEN(cmn_delete_object));
>  
> -	strncpy(req->object_name, obj_name, sizeof(req->object_name) - 1);
> +	strscpy(req->object_name, obj_name);
>  	return 0;
>  }
>  
> @@ -3856,7 +3856,7 @@ sli_cmd_common_read_object(struct sli4 *sli4, void *buf, u32 desired_read_len,
>  		cpu_to_le32(desired_read_len & SLI4_REQ_DESIRE_READLEN);
>  
>  	rd_obj->read_offset = cpu_to_le32(offset);
> -	strncpy(rd_obj->object_name, obj_name, sizeof(rd_obj->object_name) - 1);
> +	strscpy(rd_obj->object_name, obj_name);
>  	rd_obj->host_buffer_descriptor_count = cpu_to_le32(1);
>  
>  	bde = (struct sli4_bde *)rd_obj->host_buffer_descriptor;
> -- 
> 2.48.1
> 

-- 
Kees Cook