| Message ID | 20231009-strncpy-drivers-net-ethernet-brocade-bna-bfa_ioc-c-v2-1-78e0f47985d3@google.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 460c81da66f2258e504a547ea0e4facf5ed90903 |
| Headers | show |
| Series | [v2] bna: replace deprecated strncpy with strscpy_pad | expand |
On Mon, Oct 09, 2023 at 05:45:33PM +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. > > bfa_ioc_get_adapter_manufacturer() simply copies a string literal into > `manufacturer`. > > Another implementation of bfa_ioc_get_adapter_manufacturer() from > drivers/scsi/bfa/bfa_ioc.c uses memset + strscpy: > | void > | bfa_ioc_get_adapter_manufacturer(struct bfa_ioc_s *ioc, char *manufacturer) > | { > | memset((void *)manufacturer, 0, BFA_ADAPTER_MFG_NAME_LEN); > | strscpy(manufacturer, BFA_MFG_NAME, BFA_ADAPTER_MFG_NAME_LEN); > | } > > Let's use `strscpy_pad` to eliminate some redundant work while still > NUL-terminating and NUL-padding the destination buffer. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> Thanks for the update! Yeah, this looks safe to me now. Reviewed-by: Kees Cook <keescook@chromium.org>
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Mon, 09 Oct 2023 17:45:33 +0000 you 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. > > bfa_ioc_get_adapter_manufacturer() simply copies a string literal into > `manufacturer`. > > [...] Here is the summary with links: - [v2] bna: replace deprecated strncpy with strscpy_pad https://git.kernel.org/netdev/net-next/c/460c81da66f2 You are awesome, thank you!
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c index b07522ac3e74..9c80ab07a735 100644 --- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c +++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c @@ -2839,7 +2839,7 @@ bfa_ioc_get_adapter_optrom_ver(struct bfa_ioc *ioc, char *optrom_ver) static void bfa_ioc_get_adapter_manufacturer(struct bfa_ioc *ioc, char *manufacturer) { - strncpy(manufacturer, BFA_MFG_NAME, BFA_ADAPTER_MFG_NAME_LEN); + strscpy_pad(manufacturer, BFA_MFG_NAME, BFA_ADAPTER_MFG_NAME_LEN); } static void
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. bfa_ioc_get_adapter_manufacturer() simply copies a string literal into `manufacturer`. Another implementation of bfa_ioc_get_adapter_manufacturer() from drivers/scsi/bfa/bfa_ioc.c uses memset + strscpy: | void | bfa_ioc_get_adapter_manufacturer(struct bfa_ioc_s *ioc, char *manufacturer) | { | memset((void *)manufacturer, 0, BFA_ADAPTER_MFG_NAME_LEN); | strscpy(manufacturer, BFA_MFG_NAME, BFA_ADAPTER_MFG_NAME_LEN); | } Let's use `strscpy_pad` to eliminate some redundant work while still NUL-terminating and NUL-padding the destination buffer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> --- Changes in v2: - don't use sizeof on ptr (thanks Kees) - strscpy -> strscpy_pad (thanks Kees) - change subject line + commit msg to reflect above - Link to v1: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-brocade-bna-bfa_ioc-c-v1-1-8dfd30123afc@google.com --- Note: build-tested only. --- drivers/net/ethernet/brocade/bna/bfa_ioc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 change-id: 20231005-strncpy-drivers-net-ethernet-brocade-bna-bfa_ioc-c-68f13966f388 Best regards, -- Justin Stitt <justinstitt@google.com>