diff options
author | Justin Stitt <justinstitt@google.com> | 2024-02-27 02:53:44 +0300 |
---|---|---|
committer | Martin K. Petersen <martin.petersen@oracle.com> | 2024-02-27 05:18:52 +0300 |
commit | e100c01efa85c8a0ee7527bf28ef7ea7c3ca57e1 (patch) | |
tree | 3fe9ed92d4760500b0717d7858ba2ace9d7a625e /drivers/scsi/mvumi.c | |
parent | 37126399da15e1d53da93c0282aca539bccc891b (diff) | |
download | linux-e100c01efa85c8a0ee7527bf28ef7ea7c3ca57e1.tar.xz |
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 [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
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>
Diffstat (limited to 'drivers/scsi/mvumi.c')
0 files changed, 0 insertions, 0 deletions