Message ID | 20230914-strncpy-drivers-hid-uhid-c-v1-1-18a190060d8d@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp782660vqi; Thu, 14 Sep 2023 20:41:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF4RIogBcZn2lHY9WJp0GslMIhm15CvvmF85BKyhX5JTs0RSEn3md86h42wcNlVlLEa4JFx X-Received: by 2002:a17:90a:5908:b0:26f:4685:5b6c with SMTP id k8-20020a17090a590800b0026f46855b6cmr5072946pji.19.1694749312331; Thu, 14 Sep 2023 20:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694749312; cv=none; d=google.com; s=arc-20160816; b=aO61Xu6TxolB383GHygSh+CW/GUQxvmICgKkbumFlCJxFpr3g5mMgXbBcnEgUvV/Bj W2CHtiHSPpBVjEHWbSZCgpvQe2N83yNkwFZ3tg9kgb47JXiFMYnUj0e9MhDvclNrd8rk B91MPHq9+/C6wJGU5/GXNK4N5iWaJl7PB+T0f7zsELwmh5ccP3IXhKG4HyCa/VD/RBLS 2+FIr2JC5g5wIUSBgRe5Is/ru59u2li9wtBZgx/Wqfm20pweynbZOvel16r6lV0CNbJy 67LcEM9rZxx/sr2IYUwSRGg15ifEYbrSFOTlGtGyluRYrtE5IMPKyF21bpBmuorBKlLn jn3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=WlEmBKsST15BXxXfgVar1XzghXpy2BhN9U0IxRoXCQE=; fh=7m7a20AGeCYckWnP9LQkHxxqLvIuK0f2cl+tz7DHF+U=; b=AMM7+ZFK9pK4WNgYMZUrGshigPpGDq/pIctXYqw6qZ8ueJYI1nVmHGV67QGZCtA/+d NI92UQBfG0qybc0Zp5hyO4RroeJOxeX81+g6p2VSJIdd6GqVRTeIfNwZSzS8AQ4OgsKe SP+Ws5fO0EaaKMFxLzh/OvCgYB1v+aVNv6sPt+6pdT22/bfAHts8WJeJ0fHByvFLX1rW odo48qKzBjyHenh7CjQDUeFRK840N2XjjHBkvVwbFkdy0cfoMfLOPFOSvqXW47PpEKGW KMnh9ws155OOnbMCsS1+o4P6td20DnMTrUU6MGRTXw23Z4bFjvRDw1viFG4OT+fvGUpW U22Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=PaYMZoQz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id i3-20020a63e903000000b00565eb0cf702si2623397pgh.310.2023.09.14.20.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 20:41:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=PaYMZoQz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id D23CF83797CC; Thu, 14 Sep 2023 15:47:35 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230167AbjINWrb (ORCPT <rfc822;pwkd43@gmail.com> + 33 others); Thu, 14 Sep 2023 18:47:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230170AbjINWra (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 18:47:30 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8F9B2711 for <linux-kernel@vger.kernel.org>; Thu, 14 Sep 2023 15:47:25 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d81873bf443so1607542276.1 for <linux-kernel@vger.kernel.org>; Thu, 14 Sep 2023 15:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694731645; x=1695336445; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=WlEmBKsST15BXxXfgVar1XzghXpy2BhN9U0IxRoXCQE=; b=PaYMZoQzQ6DiCCY1Khy+ts0DFKWlN5CH+6GQOuWvaoucwuopd5LO7fmc/OKtZF/QXO pU0r607zjhM8We2E93VejyCu2XgYzY7tBCNVI1Ke5rWM8K7bRchg/YkqSF2IJTDo9kw+ eX4MKOxy9CPsHqdARDzdGFQhSi/9mVpdVfugsaSO1JhZmmGtpaSKaxh+uJoABzAlnHwX cD+fJZnheQHSG+L06RZeNlh9B2dSEKcM1nl/Ur7e+prSSeTexZlegtuXAeKU0KzLKUWq cVbwpnyiPj2yGXD5Acjy80DAiVBKnagdVBs3m4qWbrS766Be+JYUpF5SDRcfWBWv5VLh VSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694731645; x=1695336445; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WlEmBKsST15BXxXfgVar1XzghXpy2BhN9U0IxRoXCQE=; b=mEFykHIqgn0gQd8i20yYf+HOIRV6hlbS7oOdH6A5HvFmDUQ7CZa/W8arwrstLs8w5T Z1RBIaP52nclZccISJC9WTiFmdZH3ECBM6+HXl8QhNkcIYccBfOaZ9uKQUZL6/ZZJP8l UEj/rieqX+6khGs+4XCyNsyeYS0rdRMD6Q1ResJBbxdOkpQNVA4NqJhQY+D3cnNKcWd6 MFFCtx0mVtI+OpGEWk24Zs/egBnfiBXhNyTt+3ts2qP0+kJ+ts+U1nd1Jl/tw0HEEH4v 6VtyVZJnqFD3pXfWJq0WGJnKLOjQ3V8Nq4/m0WxdQ3MXpG+DSoulWKb1SfqqwHet9WES 8vLw== X-Gm-Message-State: AOJu0YyS9mSJZ0F30HDrGxgntfliQTrrmWqRvBW5ss1bX7MpxqZeJzw2 /RSOrSLuJKP17lFXAHfNEBbU7SRVZ7X423AsIA== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a5b:481:0:b0:d80:bea:ca87 with SMTP id n1-20020a5b0481000000b00d800beaca87mr170215ybp.1.1694731645064; Thu, 14 Sep 2023 15:47:25 -0700 (PDT) Date: Thu, 14 Sep 2023 22:47:21 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAHmNA2UC/x3MPQqEQAxA4atIagP+jLrrVRYLmURNM0riiiLe3 dHmwde8E4xV2KBNTlDexGQOEXmagJ/6MDIKRUORFWX2zR3aqsEvB5LKxmo4CeH/icfe1dVQcvN xRBAHi/Ig+zv/ddd1A6Gwul9sAAAA X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1694731644; l=2748; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=Ro3W2l30+BkUgaszKfSJpsko0I3zSOwBNarLcip1Cv0=; b=+Ja/3VwcQv8Olj4st1v7gaQMddtIhh5AF/TwEtWpW6owvTXLz0/I8erXLOUpXoFmb5Z9njm4T vZydOgdhr/SDE99w0xuyh/SH2rl1X/0la8SdmEemgGQah5zf2h7fMX+ X-Mailer: b4 0.12.3 Message-ID: <20230914-strncpy-drivers-hid-uhid-c-v1-1-18a190060d8d@google.com> Subject: [PATCH] HID: uhid: refactor deprecated strncpy From: Justin Stitt <justinstitt@google.com> To: David Rheinsberg <david@readahead.eu>, Jiri Kosina <jikos@kernel.org>, Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Kees Cook <keescook@chromium.org>, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 14 Sep 2023 15:47:35 -0700 (PDT) X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777073454630333187 X-GMAIL-MSGID: 1777073454630333187 |
Series |
HID: uhid: refactor deprecated strncpy
|
|
Commit Message
Justin Stitt
Sept. 14, 2023, 10:47 p.m. UTC
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on the destination buffer without
unnecessarily NUL-padding.
Looking at: Commit 4d26d1d1e806 ("Revert "HID: uhid: use strlcpy() instead of strncpy()"")
we see referenced the fact that many attempts have been made to change
these strncpy's into strlcpy to no success. I think strscpy is an
objectively better interface here as it doesn't unnecessarily NUL-pad
the destination buffer whilst allowing us to drop the `len = min(...)`
pattern as strscpy will implicitly limit the number of bytes copied by
the smaller of its dest and src arguments.
So while the existing code may not have a bug (i.e: overread problems)
we should still favor strscpy due to readability (plus a very slight
performance boost).
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
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
drivers/hid/uhid.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
---
base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec
change-id: 20230914-strncpy-drivers-hid-uhid-c-a465f3e784dd
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Thu, Sep 14, 2023 at 10:47:21PM +0000, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > We should prefer more robust and less ambiguous string interfaces. > > A suitable replacement is `strscpy` [2] due to the fact that it > guarantees NUL-termination on the destination buffer without > unnecessarily NUL-padding. > > Looking at: Commit 4d26d1d1e806 ("Revert "HID: uhid: use strlcpy() instead of strncpy()"") > we see referenced the fact that many attempts have been made to change > these strncpy's into strlcpy to no success. I think strscpy is an > objectively better interface here as it doesn't unnecessarily NUL-pad > the destination buffer whilst allowing us to drop the `len = min(...)` > pattern as strscpy will implicitly limit the number of bytes copied by > the smaller of its dest and src arguments. I think the worry here is that ev->u.create2.name may not be %NUL terminated. But I think that doesn't matter, see below... Also, note, this should CC David Herrmann <dh.herrmann@gmail.com> (now added). > So while the existing code may not have a bug (i.e: overread problems) > we should still favor strscpy due to readability (plus a very slight > performance boost). > > 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 > Cc: Kees Cook <keescook@chromium.org> > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > drivers/hid/uhid.c | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c > index 4588d2cd4ea4..00e1566ad37b 100644 > --- a/drivers/hid/uhid.c > +++ b/drivers/hid/uhid.c > @@ -490,7 +490,7 @@ static int uhid_dev_create2(struct uhid_device *uhid, > const struct uhid_event *ev) > { > struct hid_device *hid; > - size_t rd_size, len; > + size_t rd_size; > void *rd_data; > int ret; > > @@ -514,13 +514,9 @@ static int uhid_dev_create2(struct uhid_device *uhid, > goto err_free; > } > > - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ > - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; > - strncpy(hid->name, ev->u.create2.name, len); > - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; > - strncpy(hid->phys, ev->u.create2.phys, len); > - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; > - strncpy(hid->uniq, ev->u.create2.uniq, len); ev->u.create2 is: struct uhid_create2_req { __u8 name[128]; __u8 phys[64]; __u8 uniq[64]; ... hid is: struct hid_device { /* device report descriptor */ ... char name[128]; /* Device name */ char phys[64]; /* Device physical location */ char uniq[64]; /* Device unique identifier (serial #) */ So these "min" calls are redundant -- it wants to copy at most 1 less so it can be %NUL terminated. Which is what strscpy() already does. And source and dest are the same size, so we can't over-read source if it weren't terminated (since strscpy won't overread like strlcpy). > + strscpy(hid->name, ev->u.create2.name, sizeof(hid->name)); > + strscpy(hid->phys, ev->u.create2.phys, sizeof(hid->phys)); > + strscpy(hid->uniq, ev->u.create2.uniq, sizeof(hid->uniq)); Reviewed-by: Kees Cook <keescook@chromium.org> -Kees > > hid->ll_driver = &uhid_hid_driver; > hid->bus = ev->u.create2.bus; > > --- > base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec > change-id: 20230914-strncpy-drivers-hid-uhid-c-a465f3e784dd > > Best regards, > -- > Justin Stitt <justinstitt@google.com> >
Hi On Fri, Sep 15, 2023, at 7:13 AM, Kees Cook wrote: >> - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ >> - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; >> - strncpy(hid->name, ev->u.create2.name, len); >> - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; >> - strncpy(hid->phys, ev->u.create2.phys, len); >> - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; >> - strncpy(hid->uniq, ev->u.create2.uniq, len); > > ev->u.create2 is: > struct uhid_create2_req { > __u8 name[128]; > __u8 phys[64]; > __u8 uniq[64]; > ... > > hid is: > struct hid_device { /* device report descriptor */ > ... > char name[128]; /* Device name */ > char phys[64]; /* Device physical location */ > char uniq[64]; /* Device unique identifier (serial #) */ > > So these "min" calls are redundant -- it wants to copy at most 1 less so > it can be %NUL terminated. Which is what strscpy() already does. And > source and dest are the same size, so we can't over-read source if it > weren't terminated (since strscpy won't overread like strlcpy). I *really* think we should keep the `min` calls. The compiler should already optimize them away, as both arguments are compile-time constants. There is no inherent reason why source and target are equal in size. Yes, it is unlikely to change, but I don't understand why we would want to implicitly rely on it, rather than make the compiler verify it for us. And `struct hid_device` is very much allowed to change in the future. As an alternative, you can use BUILD_BUG_ON() and verify both are equal in length. Thanks David
On Fri, Sep 15, 2023 at 09:36:23AM +0200, David Rheinsberg wrote: > Hi > > On Fri, Sep 15, 2023, at 7:13 AM, Kees Cook wrote: > >> - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ > >> - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; > >> - strncpy(hid->name, ev->u.create2.name, len); > >> - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; > >> - strncpy(hid->phys, ev->u.create2.phys, len); > >> - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; > >> - strncpy(hid->uniq, ev->u.create2.uniq, len); > > > > ev->u.create2 is: > > struct uhid_create2_req { > > __u8 name[128]; > > __u8 phys[64]; > > __u8 uniq[64]; > > ... > > > > hid is: > > struct hid_device { /* device report descriptor */ > > ... > > char name[128]; /* Device name */ > > char phys[64]; /* Device physical location */ > > char uniq[64]; /* Device unique identifier (serial #) */ > > > > So these "min" calls are redundant -- it wants to copy at most 1 less so > > it can be %NUL terminated. Which is what strscpy() already does. And > > source and dest are the same size, so we can't over-read source if it > > weren't terminated (since strscpy won't overread like strlcpy). > > I *really* think we should keep the `min` calls. The compiler > should already optimize them away, as both arguments are compile-time > constants. There is no inherent reason why source and target are equal in > size. Yes, it is unlikely to change, but I don't understand why we would > want to implicitly rely on it, rather than make the compiler verify it for > us. And `struct hid_device` is very much allowed to change in the future. > > As an alternative, you can use BUILD_BUG_ON() and verify both are equal in length. If we can't depend on ev->u.create2.name/phys/uniq being %NUL-terminated, we've already done the "min" calculations, and we've already got the dest zeroed, then I suspect the thing to do is just use memcpy instead of strncpy (or strscpy).
Hey On Fri, Sep 15, 2023, at 10:48 PM, Kees Cook wrote: > On Fri, Sep 15, 2023 at 09:36:23AM +0200, David Rheinsberg wrote: >> Hi >> >> On Fri, Sep 15, 2023, at 7:13 AM, Kees Cook wrote: >> >> - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ >> >> - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; >> >> - strncpy(hid->name, ev->u.create2.name, len); >> >> - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; >> >> - strncpy(hid->phys, ev->u.create2.phys, len); >> >> - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; >> >> - strncpy(hid->uniq, ev->u.create2.uniq, len); >> > >> > ev->u.create2 is: >> > struct uhid_create2_req { >> > __u8 name[128]; >> > __u8 phys[64]; >> > __u8 uniq[64]; >> > ... >> > >> > hid is: >> > struct hid_device { /* device report descriptor */ >> > ... >> > char name[128]; /* Device name */ >> > char phys[64]; /* Device physical location */ >> > char uniq[64]; /* Device unique identifier (serial #) */ >> > >> > So these "min" calls are redundant -- it wants to copy at most 1 less so >> > it can be %NUL terminated. Which is what strscpy() already does. And >> > source and dest are the same size, so we can't over-read source if it >> > weren't terminated (since strscpy won't overread like strlcpy). >> >> I *really* think we should keep the `min` calls. The compiler >> should already optimize them away, as both arguments are compile-time >> constants. There is no inherent reason why source and target are equal in >> size. Yes, it is unlikely to change, but I don't understand why we would >> want to implicitly rely on it, rather than make the compiler verify it for >> us. And `struct hid_device` is very much allowed to change in the future. >> >> As an alternative, you can use BUILD_BUG_ON() and verify both are equal in length. > > If we can't depend on ev->u.create2.name/phys/uniq being %NUL-terminated, > we've already done the "min" calculations, and we've already got the > dest zeroed, then I suspect the thing to do is just use memcpy instead > of strncpy (or strscpy). If you use memcpy, you might copy garbage trailing the terminating zero. This is not particularly wrong, but also not really nice if user-space relies on the kernel to treat it as a string. You don't know whether a query of the string returns trailing bytes, and thus might expose data that user-space did not intend to share. I mean, this is why the code uses strncpy(). Thanks David
On Mon, Sep 18, 2023 at 09:37:53AM +0200, David Rheinsberg wrote: > Hey > > On Fri, Sep 15, 2023, at 10:48 PM, Kees Cook wrote: > > On Fri, Sep 15, 2023 at 09:36:23AM +0200, David Rheinsberg wrote: > >> Hi > >> > >> On Fri, Sep 15, 2023, at 7:13 AM, Kees Cook wrote: > >> >> - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ > >> >> - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; > >> >> - strncpy(hid->name, ev->u.create2.name, len); > >> >> - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; > >> >> - strncpy(hid->phys, ev->u.create2.phys, len); > >> >> - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; > >> >> - strncpy(hid->uniq, ev->u.create2.uniq, len); > >> > > >> > ev->u.create2 is: > >> > struct uhid_create2_req { > >> > __u8 name[128]; > >> > __u8 phys[64]; > >> > __u8 uniq[64]; > >> > ... > >> > > >> > hid is: > >> > struct hid_device { /* device report descriptor */ > >> > ... > >> > char name[128]; /* Device name */ > >> > char phys[64]; /* Device physical location */ > >> > char uniq[64]; /* Device unique identifier (serial #) */ > >> > > >> > So these "min" calls are redundant -- it wants to copy at most 1 less so > >> > it can be %NUL terminated. Which is what strscpy() already does. And > >> > source and dest are the same size, so we can't over-read source if it > >> > weren't terminated (since strscpy won't overread like strlcpy). > >> > >> I *really* think we should keep the `min` calls. The compiler > >> should already optimize them away, as both arguments are compile-time > >> constants. There is no inherent reason why source and target are equal in > >> size. Yes, it is unlikely to change, but I don't understand why we would > >> want to implicitly rely on it, rather than make the compiler verify it for > >> us. And `struct hid_device` is very much allowed to change in the future. > >> > >> As an alternative, you can use BUILD_BUG_ON() and verify both are equal in length. > > > > If we can't depend on ev->u.create2.name/phys/uniq being %NUL-terminated, > > we've already done the "min" calculations, and we've already got the > > dest zeroed, then I suspect the thing to do is just use memcpy instead > > of strncpy (or strscpy). > > If you use memcpy, you might copy garbage trailing the terminating zero. This is not particularly wrong, but also not really nice if user-space relies on the kernel to treat it as a string. You don't know whether a query of the string returns trailing bytes, and thus might expose data that user-space did not intend to share. > > I mean, this is why the code uses strncpy(). Justin, can you respin this patch (with an updated Subject and commit log), and add BUILD_BUG_ON() to verify the sizes are the same in addition to what you already had in the original patch? I think that'll give us the right balance between correctness, readability, and future-proofing. -Kees
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c index 4588d2cd4ea4..00e1566ad37b 100644 --- a/drivers/hid/uhid.c +++ b/drivers/hid/uhid.c @@ -490,7 +490,7 @@ static int uhid_dev_create2(struct uhid_device *uhid, const struct uhid_event *ev) { struct hid_device *hid; - size_t rd_size, len; + size_t rd_size; void *rd_data; int ret; @@ -514,13 +514,9 @@ static int uhid_dev_create2(struct uhid_device *uhid, goto err_free; } - /* @hid is zero-initialized, strncpy() is correct, strlcpy() not */ - len = min(sizeof(hid->name), sizeof(ev->u.create2.name)) - 1; - strncpy(hid->name, ev->u.create2.name, len); - len = min(sizeof(hid->phys), sizeof(ev->u.create2.phys)) - 1; - strncpy(hid->phys, ev->u.create2.phys, len); - len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1; - strncpy(hid->uniq, ev->u.create2.uniq, len); + strscpy(hid->name, ev->u.create2.name, sizeof(hid->name)); + strscpy(hid->phys, ev->u.create2.phys, sizeof(hid->phys)); + strscpy(hid->uniq, ev->u.create2.uniq, sizeof(hid->uniq)); hid->ll_driver = &uhid_hid_driver; hid->bus = ev->u.create2.bus;