| Message ID | 20231005-strncpy-drivers-net-ethernet-cavium-liquidio-octeon_device-c-v1-1-9a207cef9438@google.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c0423539559547d49cb62e76574599593829dcf8 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | cavium/liquidio: replace deprecated strncpy with strscpy | expand |
On Thu, Oct 05, 2023 at 10:52:34PM +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. > > We expect `app_name` to be NUL-terminated: > dev_info(&oct->pci_dev->dev, > "Running %s (%llu Hz)\n", > app_name, CVM_CAST64(cs->corefreq)); > ... and it seems NUL-padding is not required, let's opt for strscpy(). > > For `oct->boardinfo.name/serial_number` let's opt for strscpy() as well > since it is expected to be NUL-terminated and does not require > NUL-padding as `oct` is zero-initialized in octeon_device.c +707: > | buf = vzalloc(size); > | if (!buf) > | return NULL; > | > | oct = (struct octeon_device *)buf; > > 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> > --- > Note: build-tested only. > --- > drivers/net/ethernet/cavium/liquidio/octeon_device.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c > index 364f4f912dc2..6b6cb73482d7 100644 > --- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c > +++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c > @@ -1217,10 +1217,10 @@ int octeon_core_drv_init(struct octeon_recv_info *recv_info, void *buf) > goto core_drv_init_err; > } > > - strncpy(app_name, > + strscpy(app_name, > get_oct_app_string( > (u32)recv_pkt->rh.r_core_drv_init.app_mode), > - sizeof(app_name) - 1); > + sizeof(app_name)); Direct replacement, good. > oct->app_mode = (u32)recv_pkt->rh.r_core_drv_init.app_mode; > if (recv_pkt->rh.r_core_drv_init.app_mode == CVM_DRV_NIC_APP) { > oct->fw_info.max_nic_ports = > @@ -1257,9 +1257,10 @@ int octeon_core_drv_init(struct octeon_recv_info *recv_info, void *buf) > memcpy(cs, get_rbd( > recv_pkt->buffer_ptr[0]) + OCT_DROQ_INFO_SIZE, sizeof(*cs)); > > - strncpy(oct->boardinfo.name, cs->boardname, OCT_BOARD_NAME); > - strncpy(oct->boardinfo.serial_number, cs->board_serial_number, > - OCT_SERIAL_LEN); > + strscpy(oct->boardinfo.name, cs->boardname, > + sizeof(oct->boardinfo.name)); > + strscpy(oct->boardinfo.serial_number, cs->board_serial_number, > + sizeof(oct->boardinfo.serial_number)); struct octeon_board_info { char name[OCT_BOARD_NAME]; char serial_number[OCT_SERIAL_LEN]; Good, sizeof()s match. 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 Thu, 05 Oct 2023 22:52:34 +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. > > We expect `app_name` to be NUL-terminated: > dev_info(&oct->pci_dev->dev, > "Running %s (%llu Hz)\n", > app_name, CVM_CAST64(cs->corefreq)); > ... and it seems NUL-padding is not required, let's opt for strscpy(). > > [...] Here is the summary with links: - cavium/liquidio: replace deprecated strncpy with strscpy https://git.kernel.org/netdev/net-next/c/c04235395595 You are awesome, thank you!
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c index 364f4f912dc2..6b6cb73482d7 100644 --- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c +++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c @@ -1217,10 +1217,10 @@ int octeon_core_drv_init(struct octeon_recv_info *recv_info, void *buf) goto core_drv_init_err; } - strncpy(app_name, + strscpy(app_name, get_oct_app_string( (u32)recv_pkt->rh.r_core_drv_init.app_mode), - sizeof(app_name) - 1); + sizeof(app_name)); oct->app_mode = (u32)recv_pkt->rh.r_core_drv_init.app_mode; if (recv_pkt->rh.r_core_drv_init.app_mode == CVM_DRV_NIC_APP) { oct->fw_info.max_nic_ports = @@ -1257,9 +1257,10 @@ int octeon_core_drv_init(struct octeon_recv_info *recv_info, void *buf) memcpy(cs, get_rbd( recv_pkt->buffer_ptr[0]) + OCT_DROQ_INFO_SIZE, sizeof(*cs)); - strncpy(oct->boardinfo.name, cs->boardname, OCT_BOARD_NAME); - strncpy(oct->boardinfo.serial_number, cs->board_serial_number, - OCT_SERIAL_LEN); + strscpy(oct->boardinfo.name, cs->boardname, + sizeof(oct->boardinfo.name)); + strscpy(oct->boardinfo.serial_number, cs->board_serial_number, + sizeof(oct->boardinfo.serial_number)); octeon_swap_8B_data((u64 *)cs, (sizeof(*cs) >> 3));
`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 `app_name` to be NUL-terminated: dev_info(&oct->pci_dev->dev, "Running %s (%llu Hz)\n", app_name, CVM_CAST64(cs->corefreq)); ... and it seems NUL-padding is not required, let's opt for strscpy(). For `oct->boardinfo.name/serial_number` let's opt for strscpy() as well since it is expected to be NUL-terminated and does not require NUL-padding as `oct` is zero-initialized in octeon_device.c +707: | buf = vzalloc(size); | if (!buf) | return NULL; | | oct = (struct octeon_device *)buf; 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> --- Note: build-tested only. --- drivers/net/ethernet/cavium/liquidio/octeon_device.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 change-id: 20231005-strncpy-drivers-net-ethernet-cavium-liquidio-octeon_device-c-3579264bf805 Best regards, -- Justin Stitt <justinstitt@google.com>