From: Jason Wang
> Sent: 20 December 2021 03:24
>
> 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 <wangbor...@cdjrlc.com>
> ---
> arch/powerpc/platforms/pasemi/misc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pasemi/misc.c
> b/arch/powerpc/platforms/pasemi/misc.c
> index 1bf65d02d3ba..06a1ffd43bfe 100644
> --- a/arch/powerpc/platforms/pasemi/misc.c
> +++ b/arch/powerpc/platforms/pasemi/misc.c
> @@ -35,7 +35,7 @@ static int __init find_i2c_driver(struct device_node *node,
> for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
> if (!of_device_is_compatible(node, i2c_devices[i].of_device))
> continue;
> - if (strlcpy(info->type, i2c_devices[i].i2c_type,
> + if (strscpy(info->type, i2c_devices[i].i2c_type,
> I2C_NAME_SIZE) >= I2C_NAME_SIZE)
> return -ENOMEM;
Isn't that the wrong overflow check?
Doesn't strscpy() return a -ve errno value on failure
(just to cause a different buffer overflow issue?)
Not that any kind of overflow is actually possible in that over-engineered
code fragment.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
