Message ID | 20231012-strncpy-drivers-net-hamradio-baycom_epp-c-v1-1-8f4097538ee4@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp1510447vqb; Thu, 12 Oct 2023 14:33:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFLFH6clOJgSRYwERB4x4p2rHgt8I/DvaBK7Dy4r6aXFlHYyLQJXjRNV58AalxG6cBR5o5o X-Received: by 2002:a05:6a00:3ab:b0:68f:c309:9736 with SMTP id y43-20020a056a0003ab00b0068fc3099736mr27130579pfs.3.1697146434799; Thu, 12 Oct 2023 14:33:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697146434; cv=none; d=google.com; s=arc-20160816; b=a+ecJCUjqBTXhl25M/Oop6yTXO0bUXBnAdnKERbO/ZqbpGxL7kfsOv6X3PW9dMIJo0 VicxupI0xHtm8iYkhvEJrUOCbDJTqcWlYvauh9ZnoBpLAL3XgT/MIULde/5joBuK+Whs lIwfzbpr6oqMLsBnNwcqEjc3lg0cdVzi6cEmjd/jyPct+IHuYjx4jaPQVfJZLvk6jQXw 0Iqyc5dVEfmIdhh7CS+svAlNsLytbZfW7YOBqb3WsqojnDe47QnYq1z/ysxsP2trKHHz MwbX+yC/YRxu7DWOBAVdqlUiGL1rhKGs7wcU98tLT+WmuzAtTIp0DXs9OMq734R251WY isNQ== 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=hYSTVrCouVWE319gwaD4mDagDCplKYTMAl9k6NN6p0U=; fh=lh8+h8Cub4sDTTYv7AU2zOgI9Rk3UB2OyzHhrOMnBQo=; b=b0tCeSUwC+cUgQQnK9SUohmIBBPu4Kql/p3nQaYusG5ezNZko/sxiM5Oa5NM0I6y4n y40rkLkj5Pr5rk0ubPJ81swtxx9CIXoCoDvasFF9yhqCKSTLuUSpeShfESABmycHzMGd ibMa7gFBalfhT1sAx8Q7AtqrtV2Anu8UutsPZKcxCKIC525uTDl/MnI2827QgJIDY/0v v3ID6jRRzTI/9eeSbiaZ4S7l4nYOAioMfEvoDEdhEghcOf9EffvzGPBsgTozM8PC1fqX KmTsvdmFYbPM0a+Jj2RVM3X/BoQ/1dCZKh/n1uhDM4XCef8CoCAheVKV5yFX8GbGHxx4 j+DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=j3CIIv3g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id y22-20020a056a00191600b00690c0051dcdsi6543779pfi.143.2023.10.12.14.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 14:33:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=j3CIIv3g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (Postfix) with ESMTP id AF0BF81ABACC; Thu, 12 Oct 2023 14:33:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442945AbjJLVdi (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Thu, 12 Oct 2023 17:33:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1442946AbjJLVdg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 12 Oct 2023 17:33:36 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 410E4DC for <linux-kernel@vger.kernel.org>; Thu, 12 Oct 2023 14:33:34 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a7ed6903a6so21450027b3.2 for <linux-kernel@vger.kernel.org>; Thu, 12 Oct 2023 14:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697146413; x=1697751213; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=hYSTVrCouVWE319gwaD4mDagDCplKYTMAl9k6NN6p0U=; b=j3CIIv3gCVmU9R0l2dslE+oPVXaVD1Wa12FQFQirrDPseN8A6dyuCjQkG4CehA7t1K zIKzQ/jnbO72wkULosOjGE3p2+FlOAojLHQt6Yhpgen1kY01ui21t7uupxt9dbDP7NBW Xsl7U0Ceuwcax1UQPZSnQ4gZzAz5K+Q20nqi2u7o2OnxBs0I4R91gOBp4hg0G4OTFwzC M/yTkOKiVBVDy/udMkd/tg9/nBLXJZ8WYkmYMYiW3RKBbYU40THgrA0nEhjEpn4veDd7 SL55rM0LcZY4zrw+T2zRKByaW6gfhT1IBAhRWlYd7QkxJM1KA4s40A2t6S0cvivV35Gg IlRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697146413; x=1697751213; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hYSTVrCouVWE319gwaD4mDagDCplKYTMAl9k6NN6p0U=; b=V6Jmmp6FtBe0JPv294pDgMzfjmkhal1T6pcOLE3bzeNXB3wXFI6bYdhJiTJrEMoFP2 mzPggEoaExdSlUJuTBzJENKZFR7YPGz2gH+iKSQfVokFVCSQqj3L9J393wCTwA8GKtfG M79UfH6MBH07Mh3KF54XWP8IBxQ3BCqreDH/mwlNCW3PVudSU5mlIPl2CgJD/bdnFFGM Z0i7CBtoOXK4qsWc+txD31okFiFafqlaBhW7FNMeCMwgQs/7VGY12x7MZP3ZXxI6QnMp 8KX8yFMqgEvrXDxg2oBgX4cnwf7rBxHZdokmO0SaUIVcJRPBd2c11LWIfF8MdLI3TN20 jZhA== X-Gm-Message-State: AOJu0Ywg9d5cPb8Q/KWBcx/bRL6mBg7O3o3roSf/yRJgcJXiCE0U86jT apS0KNt3CljkaW02OZq6PnJ2dh5RHMhAQPcX6w== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:361e:0:b0:d9a:6b49:433d with SMTP id d30-20020a25361e000000b00d9a6b49433dmr164492yba.6.1697146413504; Thu, 12 Oct 2023 14:33:33 -0700 (PDT) Date: Thu, 12 Oct 2023 21:33:32 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIACxmKGUC/x3NwQqDMAyA4VeRnBcwVcbcq4wxahpnDrYlFZmI7 27Z8bv8/wFFTKXAsznAZNOiKVbQrQGeffwKaqgG17qOWnJYVoucdwymm1jBKCvOfjEfNOHod07 LR3JGxrsQ8dA/unGYoPayyaS//+v1Ps8LZduKZXsAAAA= X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1697146412; l=2666; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=GEipWyiXVMyF4NttCT1RNho91xfYNJdcMAw0nEmg9aU=; b=x7E6v7q0m/O/QprpRqxWPblE89KJH/8AAzMt116g3gzow9M2f7BwcEy/LlgWAsSKhgaWC4jk0 9TdRQ3QWP87CvCdaWXAAGHMw7Gj12xOELpNOijQRm8halo5ZaaCR6zx X-Mailer: b4 0.12.3 Message-ID: <20231012-strncpy-drivers-net-hamradio-baycom_epp-c-v1-1-8f4097538ee4@google.com> Subject: [PATCH] hamradio: replace deprecated strncpy with strscpy From: Justin Stitt <justinstitt@google.com> To: Thomas Sailer <t.sailer@alumni.ethz.ch>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: linux-hams@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" 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 agentk.vger.email 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 (agentk.vger.email [0.0.0.0]); Thu, 12 Oct 2023 14:33:52 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779587020035701055 X-GMAIL-MSGID: 1779587020035701055 |
Series |
hamradio: replace deprecated strncpy with strscpy
|
|
Commit Message
Justin Stitt
Oct. 12, 2023, 9:33 p.m. UTC
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 expect both hi.data.modename and hi.data.drivername to be
NUL-terminated but not necessarily NUL-padded which is evident by its
usage with sprintf:
| sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s",
| bc->cfg.intclk ? "int" : "ext",
| bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps,
| bc->cfg.loopback ? ",loopback" : "");
Note that this data is copied out to userspace with:
| if (copy_to_user(data, &hi, sizeof(hi)))
... however, the data was also copied FROM the user here:
| if (copy_from_user(&hi, data, sizeof(hi)))
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.
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.
Also, there are 33 instances of trailing whitespace in this file alone.
I've opted to not remove them in this patch.
---
drivers/net/hamradio/baycom_epp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
change-id: 20231012-strncpy-drivers-net-hamradio-baycom_epp-c-6e11c9483b9f
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be > NUL-terminated but not necessarily NUL-padded which is evident by its > usage with sprintf: > | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", > | bc->cfg.intclk ? "int" : "ext", > | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, > | bc->cfg.loopback ? ",loopback" : ""); > > Note that this data is copied out to userspace with: > | if (copy_to_user(data, &hi, sizeof(hi))) > ... however, the data was also copied FROM the user here: > | if (copy_from_user(&hi, data, sizeof(hi))) Thanks Justin, I see that too. Perhaps I am off the mark here, and perhaps it's out of scope for this patch, but I do think it would be nicer if the kernel only sent intended data to user-space, even if any unintended payload came from user-space. > 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. > > 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> ...
On Sun, Oct 15, 2023 at 05:06:19PM +0200, Simon Horman wrote: > On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be > > NUL-terminated but not necessarily NUL-padded which is evident by its > > usage with sprintf: > > | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", > > | bc->cfg.intclk ? "int" : "ext", > > | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, > > | bc->cfg.loopback ? ",loopback" : ""); > > > > Note that this data is copied out to userspace with: > > | if (copy_to_user(data, &hi, sizeof(hi))) > > ... however, the data was also copied FROM the user here: > > | if (copy_from_user(&hi, data, sizeof(hi))) > > Thanks Justin, > > I see that too. > > Perhaps I am off the mark here, and perhaps it's out of scope for this > patch, but I do think it would be nicer if the kernel only sent > intended data to user-space, even if any unintended payload came > from user-space. > It's kind of normal to pass user space data back to itself. We generally only worry about info leaks. regards, dan carpenter
On October 15, 2023 10:47:53 PM PDT, Dan Carpenter <dan.carpenter@linaro.org> wrote: >On Sun, Oct 15, 2023 at 05:06:19PM +0200, Simon Horman wrote: >> On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be >> > NUL-terminated but not necessarily NUL-padded which is evident by its >> > usage with sprintf: >> > | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", >> > | bc->cfg.intclk ? "int" : "ext", >> > | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, >> > | bc->cfg.loopback ? ",loopback" : ""); >> > >> > Note that this data is copied out to userspace with: >> > | if (copy_to_user(data, &hi, sizeof(hi))) >> > ... however, the data was also copied FROM the user here: >> > | if (copy_from_user(&hi, data, sizeof(hi))) >> >> Thanks Justin, >> >> I see that too. >> >> Perhaps I am off the mark here, and perhaps it's out of scope for this >> patch, but I do think it would be nicer if the kernel only sent >> intended data to user-space, even if any unintended payload came >> from user-space. >> > >It's kind of normal to pass user space data back to itself. We >generally only worry about info leaks. True but since this used to zero the rest of the buffet, let's just keep that behavior and use strscpy_pad(). -Kees
On October 16, 2023 10:01:20 AM PDT, Kees Cook <kees@kernel.org> wrote: > > >On October 15, 2023 10:47:53 PM PDT, Dan Carpenter <dan.carpenter@linaro.org> wrote: >>On Sun, Oct 15, 2023 at 05:06:19PM +0200, Simon Horman wrote: >>> On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be >>> > NUL-terminated but not necessarily NUL-padded which is evident by its >>> > usage with sprintf: >>> > | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", >>> > | bc->cfg.intclk ? "int" : "ext", >>> > | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, >>> > | bc->cfg.loopback ? ",loopback" : ""); >>> > >>> > Note that this data is copied out to userspace with: >>> > | if (copy_to_user(data, &hi, sizeof(hi))) >>> > ... however, the data was also copied FROM the user here: >>> > | if (copy_from_user(&hi, data, sizeof(hi))) >>> >>> Thanks Justin, >>> >>> I see that too. >>> >>> Perhaps I am off the mark here, and perhaps it's out of scope for this >>> patch, but I do think it would be nicer if the kernel only sent >>> intended data to user-space, even if any unintended payload came >>> from user-space. >>> >> >>It's kind of normal to pass user space data back to itself. We >>generally only worry about info leaks. > >True but since this used to zero the rest of the buffet, let's just keep that behavior and use strscpy_pad(). I'm calling all byte arrays a "buffet" from now on. ;)
On 17/10/23 04:03, Kees Cook wrote: > > > On October 16, 2023 10:01:20 AM PDT, Kees Cook <kees@kernel.org> wrote: >> >> >> On October 15, 2023 10:47:53 PM PDT, Dan Carpenter <dan.carpenter@linaro.org> wrote: >>> On Sun, Oct 15, 2023 at 05:06:19PM +0200, Simon Horman wrote: >>>> On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be >>>>> NUL-terminated but not necessarily NUL-padded which is evident by its >>>>> usage with sprintf: >>>>> | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", >>>>> | bc->cfg.intclk ? "int" : "ext", >>>>> | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, >>>>> | bc->cfg.loopback ? ",loopback" : ""); >>>>> >>>>> Note that this data is copied out to userspace with: >>>>> | if (copy_to_user(data, &hi, sizeof(hi))) >>>>> ... however, the data was also copied FROM the user here: >>>>> | if (copy_from_user(&hi, data, sizeof(hi))) >>>> >>>> Thanks Justin, >>>> >>>> I see that too. >>>> >>>> Perhaps I am off the mark here, and perhaps it's out of scope for this >>>> patch, but I do think it would be nicer if the kernel only sent >>>> intended data to user-space, even if any unintended payload came >>>> from user-space. >>>> >>> >>> It's kind of normal to pass user space data back to itself. We >>> generally only worry about info leaks. >> >> True but since this used to zero the rest of the buffet, let's just keep that behavior and use strscpy_pad(). > > I'm calling all byte arrays a "buffet" from now on. ;) > A tasteful change to the sauce I think. ;)
On Mon, Oct 16, 2023 at 3:18 PM Hugh Blemings <hugh@blemings.org> wrote: > > > > On 17/10/23 04:03, Kees Cook wrote: > > > > > > On October 16, 2023 10:01:20 AM PDT, Kees Cook <kees@kernel.org> wrote: > >> > >> > >> On October 15, 2023 10:47:53 PM PDT, Dan Carpenter <dan.carpenter@linaro.org> wrote: > >>> On Sun, Oct 15, 2023 at 05:06:19PM +0200, Simon Horman wrote: > >>>> On Thu, Oct 12, 2023 at 09:33:32PM +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 expect both hi.data.modename and hi.data.drivername to be > >>>>> NUL-terminated but not necessarily NUL-padded which is evident by its > >>>>> usage with sprintf: > >>>>> | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", > >>>>> | bc->cfg.intclk ? "int" : "ext", > >>>>> | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, > >>>>> | bc->cfg.loopback ? ",loopback" : ""); > >>>>> > >>>>> Note that this data is copied out to userspace with: > >>>>> | if (copy_to_user(data, &hi, sizeof(hi))) > >>>>> ... however, the data was also copied FROM the user here: > >>>>> | if (copy_from_user(&hi, data, sizeof(hi))) > >>>> > >>>> Thanks Justin, > >>>> > >>>> I see that too. > >>>> > >>>> Perhaps I am off the mark here, and perhaps it's out of scope for this > >>>> patch, but I do think it would be nicer if the kernel only sent > >>>> intended data to user-space, even if any unintended payload came > >>>> from user-space. > >>>> > >>> > >>> It's kind of normal to pass user space data back to itself. We > >>> generally only worry about info leaks. > >> > >> True but since this used to zero the rest of the buffet, let's just keep that behavior and use strscpy_pad(). > > > > I'm calling all byte arrays a "buffet" from now on. ;) > > > A tasteful change to the sauce I think. ;) Just perfect that this is happening on a **ham**radio driver.
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c index 83ff882f5d97..30a0fbb12b9c 100644 --- a/drivers/net/hamradio/baycom_epp.c +++ b/drivers/net/hamradio/baycom_epp.c @@ -1074,7 +1074,7 @@ static int baycom_siocdevprivate(struct net_device *dev, struct ifreq *ifr, return 0; case HDLCDRVCTL_DRIVERNAME: - strncpy(hi.data.drivername, "baycom_epp", sizeof(hi.data.drivername)); + strscpy(hi.data.drivername, "baycom_epp", sizeof(hi.data.drivername)); break; case HDLCDRVCTL_GETMODE: @@ -1091,7 +1091,7 @@ static int baycom_siocdevprivate(struct net_device *dev, struct ifreq *ifr, return baycom_setmode(bc, hi.data.modename); case HDLCDRVCTL_MODELIST: - strncpy(hi.data.modename, "intclk,extclk,intmodem,extmodem,divider=x", + strscpy(hi.data.modename, "intclk,extclk,intmodem,extmodem,divider=x", sizeof(hi.data.modename)); break;