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
| ||
|
Message-ID: <202310051610.01453F60F@keescook> Date: Thu, 5 Oct 2023 16:14:31 -0700 From: Kees Cook <keescook@...omium.org> To: Justin Stitt <justinstitt@...gle.com> Cc: Derek Chickles <dchickles@...vell.com>, Satanand Burla <sburla@...vell.com>, Felix Manlunas <fmanlunas@...vell.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH] liquidio: replace deprecated strncpy/strcpy with strscpy On Thu, Oct 05, 2023 at 09:33:19PM +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. > > NUL-padding is not required as drvinfo is memset to 0: > | memset(drvinfo, 0, sizeof(struct ethtool_drvinfo)); > > A suitable replacement is `strscpy` [2] due to the fact that it > guarantees NUL-termination on the destination buffer without > unnecessarily NUL-padding. > > 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@...r.kernel.org > Signed-off-by: Justin Stitt <justinstitt@...gle.com> > --- > Note: build-tested only. > --- > drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c > index 9d56181a301f..d3e07b6ed5e1 100644 > --- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c > +++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c > @@ -442,10 +442,11 @@ lio_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *drvinfo) > oct = lio->oct_dev; > > memset(drvinfo, 0, sizeof(struct ethtool_drvinfo)); struct ethtool_drvinfo { char driver[32]; ... char fw_version[ETHTOOL_FWVERS_LEN]; char bus_info[ETHTOOL_BUSINFO_LEN]; > - strcpy(drvinfo->driver, "liquidio"); > + strscpy(drvinfo->driver, "liquidio", sizeof(drvinfo->driver)); Yup, this is basically what FORTIFY_SOURCE will do automatically to strcpy(). > - strncpy(drvinfo->fw_version, oct->fw_info.liquidio_firmware_version, > - ETHTOOL_FWVERS_LEN); > + strscpy(drvinfo->fw_version, oct->fw_info.liquidio_firmware_version, > + sizeof(drvinfo->fw_version)); Yup, ETHTOOL_FWVERS_LEN == sizeof(drvinfo->fw_version) > - strncpy(drvinfo->bus_info, pci_name(oct->pci_dev), 32); > + strscpy(drvinfo->bus_info, pci_name(oct->pci_dev), > + sizeof(drvinfo->bus_info)); Yup, ETHTOOL_BUSINFO_LEN == sizeof(drvinfo->bus_info) > } > > static void > @@ -458,10 +459,11 @@ lio_get_vf_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *drvinfo) > oct = lio->oct_dev; > > memset(drvinfo, 0, sizeof(struct ethtool_drvinfo)); > - strcpy(drvinfo->driver, "liquidio_vf"); > - strncpy(drvinfo->fw_version, oct->fw_info.liquidio_firmware_version, > - ETHTOOL_FWVERS_LEN); > - strncpy(drvinfo->bus_info, pci_name(oct->pci_dev), 32); > + strscpy(drvinfo->driver, "liquidio_vf", sizeof(drvinfo->driver)); > + strscpy(drvinfo->fw_version, oct->fw_info.liquidio_firmware_version, > + sizeof(drvinfo->fw_version)); > + strscpy(drvinfo->bus_info, pci_name(oct->pci_dev), > + sizeof(drvinfo->bus_info)); > } Yup, looks good. Reviewed-by: Kees Cook <keescook@...omium.org> > > static int > > --- > base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 > change-id: 20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_ethtool-c-b6932c0f80f1 > > Best regards, > -- > Justin Stitt <justinstitt@...gle.com> > > -- Kees Cook
Powered by blists - more mailing lists