The strlcpy should not be used because it doesn't limit the source
length. So that it will lead some potential bugs.
But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.
Thus, replace strlcpy with strscpy.
Signed-off-by: Jason Wang <[email protected]>
---
drivers/net/ethernet/dlink/dl2k.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
index a301f7e6a440..2c67a857a42f 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -1235,8 +1235,8 @@ static void rio_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
{
struct netdev_private *np = netdev_priv(dev);
- strlcpy(info->driver, "dl2k", sizeof(info->driver));
- strlcpy(info->bus_info, pci_name(np->pdev), sizeof(info->bus_info));
+ strscpy(info->driver, "dl2k", sizeof(info->driver));
+ strscpy(info->bus_info, pci_name(np->pdev), sizeof(info->bus_info));
}
static int rio_get_link_ksettings(struct net_device *dev,
--
2.34.1
On Tue, Dec 21, 2021 at 8:14 AM Jason Wang <[email protected]> wrote:
>
> The strlcpy should not be used because it doesn't limit the source
> length. So that it will lead some potential bugs.
>
> But the strscpy doesn't require reading memory from the src string
> beyond the specified "count" bytes, and since the return value is
> easier to error-check than strlcpy()'s. In addition, the implementation
> is robust to the string changing out from underneath it, unlike the
> current strlcpy() implementation.
>
> Thus, replace strlcpy with strscpy.
>
> Signed-off-by: Jason Wang <[email protected]>
Are you trying to eliminate strlcpy() from all 800 files using it
completely? If not, I don't see a need to fix individual drivers
that use a constant source string and don't use the return
code, as the behavior should be the same.
While it seems reasonable to converge towards a more robust
string copy, none of the points you list in the changelog apply to
the function you patch here.
Arnd