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 know dev->name should be NUL-terminated based on the presence of a manual NUL-byte assignment. NUL-padding is not required as dev is already zero-allocated which renders any further NUL-byte assignments redundant: dev = pnp_alloc_dev(&pnpacpi_protocol, num, pnpid); ---> dev = kzalloc(sizeof(struct pnp_dev), GFP_KERNEL); Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. This simplifies the code and makes the intent/behavior more obvious. 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: [email protected] Signed-off-by: Justin Stitt <[email protected]> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/pnp/pnpacpi/core.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c index 6ab272c84b7b..a0927081a003 100644 --- a/drivers/pnp/pnpacpi/core.c +++ b/drivers/pnp/pnpacpi/core.c @@ -250,12 +250,9 @@ static int __init pnpacpi_add_device(struct acpi_device *device) dev->capabilities |= PNP_DISABLE; if (strlen(acpi_device_name(device))) - strncpy(dev->name, acpi_device_name(device), sizeof(dev->name)); + strscpy(dev->name, acpi_device_name(device), sizeof(dev->name)); else - strncpy(dev->name, acpi_device_bid(device), sizeof(dev->name)); - - /* Handle possible string truncation */ - dev->name[sizeof(dev->name) - 1] = '\0'; + strscpy(dev->name, acpi_device_bid(device), sizeof(dev->name)); if (dev->active) pnpacpi_parse_allocated_resource(dev); --- base-commit: dab3e01664eaddae965699f1fec776609db0ea9d change-id: 20231019-strncpy-drivers-pnp-pnpacpi-core-c-54d9bc42443e Best regards, -- Justin Stitt <[email protected]>
