Message ID | 20240320-strncpy-drivers-virt-acrn-ioreq-c-v1-1-db6996770341@google.com (mailing list archive) |
---|---|
State | Mainlined |
Commit | 61af39e1e40da1afd8803352c465a140e3d5d6ab |
Headers | show |
Series | virt: acrn: replace deprecated strncpy with strscpy | expand |
On Wed, Mar 20, 2024 at 11:27:09PM +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 can see that client->name should be NUL-terminated based on its usage > with a %s C-string format specifier. > | client->thread = kthread_run(ioreq_task, client, "VM%u-%s", > | client->vm->vmid, client->name); > > NUL-padding is not required as client is already zero-allocated: > | client = kzalloc(sizeof(*client), 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. > > Note that this patch relies on the _new_ 2-argument version of strscpy() > introduced in Commit e6584c3964f2f ("string: Allow 2-argument > strscpy()"). > > 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@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org>
On Wed, 20 Mar 2024 23:27:09 +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 can see that client->name should be NUL-terminated based on its usage > with a %s C-string format specifier. > | client->thread = kthread_run(ioreq_task, client, "VM%u-%s", > | client->vm->vmid, client->name); > > [...] Applied to for-next/hardening, thanks! [1/1] virt: acrn: replace deprecated strncpy with strscpy https://git.kernel.org/kees/c/e8a87d0cd048 Take care,
diff --git a/drivers/virt/acrn/ioreq.c b/drivers/virt/acrn/ioreq.c index 29e1ef1915fd..e94358239a4b 100644 --- a/drivers/virt/acrn/ioreq.c +++ b/drivers/virt/acrn/ioreq.c @@ -433,7 +433,7 @@ struct acrn_ioreq_client *acrn_ioreq_client_create(struct acrn_vm *vm, client->priv = priv; client->is_default = is_default; if (name) - strncpy(client->name, name, sizeof(client->name) - 1); + strscpy(client->name, name); rwlock_init(&client->range_lock); INIT_LIST_HEAD(&client->range_list); init_waitqueue_head(&client->wq);
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 can see that client->name should be NUL-terminated based on its usage with a %s C-string format specifier. | client->thread = kthread_run(ioreq_task, client, "VM%u-%s", | client->vm->vmid, client->name); NUL-padding is not required as client is already zero-allocated: | client = kzalloc(sizeof(*client), 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. Note that this patch relies on the _new_ 2-argument version of strscpy() introduced in Commit e6584c3964f2f ("string: Allow 2-argument strscpy()"). 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@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/virt/acrn/ioreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- base-commit: a4145ce1e7bc247fd6f2846e8699473448717b37 change-id: 20240320-strncpy-drivers-virt-acrn-ioreq-c-9913a5c6e2bf Best regards, -- Justin Stitt <justinstitt@google.com>