scsi: lpfc: Replace deprecated strncpy() with strscpy()
authorJustin Stitt <justinstitt@google.com>
Mon, 26 Feb 2024 23:53:44 +0000 (23:53 +0000)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 27 Feb 2024 02:18:52 +0000 (21:18 -0500)
commite100c01efa85c8a0ee7527bf28ef7ea7c3ca57e1
tree3fe9ed92d4760500b0717d7858ba2ace9d7a625e
parent37126399da15e1d53da93c0282aca539bccc891b
scsi: lpfc: Replace deprecated strncpy() with strscpy()

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 expect ae->value_string to be NUL-terminated because there's a comment
that says as much; these attr strings are also used with other string APIs,
further cementing the fact.

Now, the question of whether or not to NUL-pad the destination buffer:
lpfc_fdmi_rprt_defer() initializes vports (all zero-initialized), then we
call lpfc_fdmi_cmd() with each vport and a mask. Then, inside of
lpfc_fdmi_cmd() we check each bit in the mask to invoke the proper
callback. Importantly, the zero-initialized vport is passed in as the
"attr" parameter. Seeing this:
| struct lpfc_fdmi_attr_string *ae = attr;
... we can tell that ae->value_string is entirely zero-initialized. Due
to this, NUL-padding is _not_ required as it would be redundant.

Considering the above, a suitable replacement is strscpy() [2].

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240226-strncpy-drivers-scsi-lpfc-lpfc_ct-c-v2-1-2df2e46569b9@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/lpfc/lpfc_ct.c