Message ID | 20231010-netdev-replace-strncpy-resend-as-series-v1-0-caf9f0f2f021@google.com |
---|---|
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 ib8csp171877vqb; Tue, 10 Oct 2023 15:27:43 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHkdNBm7R26Ff4db0SlFtCGodVfdkVd8mUldc8WRjoUztS6Pj9pM/qrwbv+m2Y9yMhQwDKN X-Received: by 2002:a05:6a00:288a:b0:690:2ab8:2d67 with SMTP id ch10-20020a056a00288a00b006902ab82d67mr21772029pfb.1.1696976862876; Tue, 10 Oct 2023 15:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696976862; cv=none; d=google.com; s=arc-20160816; b=n3RbX1pub6TnswKWxNaiJA1JTOoB5rXrwxIDH+X8Z/xiwV62dCTN9VjuFdgH8TJwSg oy+nACZpwYAaGHw/rpYuFi+Cq7/+bJZGC/iIHBC76MN6YP+2l/4BsJDGgLbgEYavo1kK vA8WjsvfPh//Xb1b4w0OwL1ZATjNhgZbstfh6NFWo3Mj8WegL6w1tiXHsaaQHSv5QYRi eI3/4dDDjzI90gerb2GbXBnnRDtBeszncCv4/y5DGP9IhwLDSIEzm8zoNkzbhLswaI5+ PmnaF2KC2H9oHiO+2mWF05LVfyZSckbQ3DJ9Ni/Dk+8Ut5CyOoM4NYW6fztYBeEBiyvC VEYQ== 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=mqff+9SvB3fBY25z9tL0cer8ihfSYj7+UyD+m2ojB+8=; fh=jBrXfr1CofwHzdCs7t+hNw/6P+fbZjn/vMCgpWmT8zI=; b=BSx1nhsQNuhgSfwQQGQ+aNueXPQPtMNNCRTib9EmjSfbCbrgkm0fR8iDeqZo+PMLFk iENnQJxGvfI0bnSN+r+dghQNr193hbjh65vUJo+/SEnIlsnrWv50Q5Pke0y5inT1rHDt 9sX7uLM8k2ZAijVwkRYinpm58a51YqkV3rHbbS3LyladnmScXVB5RgeROVG+Vl8Jscjj WAWfE5gbiV0T4F2es8Xf0yF4/e/haUoCmH/jmGLPTAqMh9CfYNTfqoxRywShTmJxrjF8 g7veNsaIEJRvXHE5OmgFT7XUXK4fv1bnA56Eg1J61XaBTex0j8QP2xrZoPS4IdR2PBA6 z2yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=hn7T3SSr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 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 fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id br9-20020a056a00440900b0068fbdfa7379si10302572pfb.311.2023.10.10.15.27.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 15:27:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=hn7T3SSr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 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 fry.vger.email (Postfix) with ESMTP id 7F62783B819D; Tue, 10 Oct 2023 15:27:35 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234533AbjJJW1S (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Tue, 10 Oct 2023 18:27:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234676AbjJJW1J (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Oct 2023 18:27:09 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E85698 for <linux-kernel@vger.kernel.org>; Tue, 10 Oct 2023 15:27:06 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-d85fc108f0eso8309056276.2 for <linux-kernel@vger.kernel.org>; Tue, 10 Oct 2023 15:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696976825; x=1697581625; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=mqff+9SvB3fBY25z9tL0cer8ihfSYj7+UyD+m2ojB+8=; b=hn7T3SSrBObKD9vVFQUWWB0nrV91BOgNe+UcOcTmT7t7RawDZXZ1cJewovRKpJY0ZL oDQQx3SZtrIYHZkAxorbChMMV/t8laEMCiOFSvluVK5uf8usVUbN9g86Op0R3De/y8RT UHMY84lCwA+uc/niAkRs2scknnenKXBCHOpY9QPfTd31GMrm8/YH6+5UZ8z12ewQbrW0 qx2gfdXGw6Vr2GY77tJFbK5Tcw93lDz93bdgdOcXBBNVi8P+Y1z9racpCaowjv4GksZe nS37xTsWkfzDZS711mTKqfsPfDNil2xhuI0zMsbxYs7SvYfF4jDQz3C31RRH/vRUy4rN Cu8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696976825; x=1697581625; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mqff+9SvB3fBY25z9tL0cer8ihfSYj7+UyD+m2ojB+8=; b=CQt5flboHAqh9jFhNldY5vfh4Qi7oVqSG7+n+DABD7zf08A9YdEFJEc7TZL6EFOkx3 UFZdERs24ewJDAn4zsrexiJDfs1ufG5AGiWchLLtjsgYPlRHWDCJ3YZZQ8v2LAkNZhG8 3fP2LbigDrNpG/EwlFbhV1k6Of1g5M2C727oCps4eG11SwbFlaQ5xY5A5uAIFZbeBBvf Grwwy3J6cpnjyqawuuH6Y/O0BooU1S5QaZwLYBUdY6fcdyZYkndJehi6Jw/3HIHvVi3l e+EyoG719rwZZy6hvqvxDcsYaK20wWLQk9exmE0KMj+K7b0+TUpT251ivvd6eZAeBrLg Kb+Q== X-Gm-Message-State: AOJu0Yw1cWQcHDDWY/+E6eBBfXKGngZqOGd7h8znk4k7nL8aW2N1mYoz Vrdpty2LgE97qQuiIzRh16gG/85Ksl10rcuaQg== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:8a0d:0:b0:d81:7617:a397 with SMTP id g13-20020a258a0d000000b00d817617a397mr352834ybl.9.1696976825766; Tue, 10 Oct 2023 15:27:05 -0700 (PDT) Date: Tue, 10 Oct 2023 22:26:53 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAK3PJWUC/yXNwQrCMBCE4Vcpe3YhaUHQVxEPMTtqQGLIhtBS+ u7d6vGfwzcrKWqC0nVYqaInTd9s4U8DxXfIL3ASaxrdOHnnHWc0QeeK8gkRrK3mWBZrRRYOyn+ QBbg4cfE8PYRMKxXPNP+ebtT9MRll3Nzovm07eajTV4kAAAA= X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1696976824; l=3112; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=xvGZD5tJaO6+F4XyQY6/aAG8nI/QHpdZbkaTXLOae38=; b=ZUNsueoPkwbd0dBafrZ61XOzzilo+aMtXgdstoGrSelvS82fo2raZLSDrWZAsbk+OrkDtUx4l P1sYqwtfcssAwA1lCB1wgfMwcezaDYwjJ0lWQ8ez5Nba0zkDIaIfHu4 X-Mailer: b4 0.12.3 Message-ID: <20231010-netdev-replace-strncpy-resend-as-series-v1-0-caf9f0f2f021@google.com> Subject: [PATCH net-next 0/7] net: intel: replace deprecated strncpy uses From: Justin Stitt <justinstitt@google.com> To: Jesse Brandeburg <jesse.brandeburg@intel.com>, Tony Nguyen <anthony.l.nguyen@intel.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: linux-hardening@vger.kernel.org, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-4.8 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.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 (fry.vger.email [0.0.0.0]); Tue, 10 Oct 2023 15:27:35 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779409211126497994 X-GMAIL-MSGID: 1779409211126497994 |
Series |
net: intel: replace deprecated strncpy uses
|
|
Message
Justin Stitt
Oct. 10, 2023, 10:26 p.m. UTC
Hi,
This series aims to eliminate uses of strncpy() as it is a deprecated
interface [1] with many viable replacements available.
Predominantly, strscpy() is the go-to replacement as it guarantees
NUL-termination on the destination buffer (which strncpy does not). With
that being said, I did not identify any buffer overread problems as the
size arguments were carefully measured to leave room for trailing
NUL-bytes. Nonetheless, we should favor more robust and less ambiguous
interfaces.
Previously, each of these patches was sent individually at:
1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/
2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/
3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/
4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/
5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/
6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/
7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/
Consider these dead as this series is their new home :)
I found all these instances with: $ rg "strncpy\("
This series may collide in a not-so-nice way with [3]. This series can
go in after that one with a rebase. I'll send a v2 if necessary.
[3]: https://lore.kernel.org/netdev/20231003183603.3887546-1-jesse.brandeburg@intel.com/
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
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Justin Stitt (7):
e100: replace deprecated strncpy with strscpy
e1000: replace deprecated strncpy with strscpy
fm10k: replace deprecated strncpy with strscpy
i40e: use scnprintf over strncpy+strncat
igb: replace deprecated strncpy with strscpy
igbvf: replace deprecated strncpy with strscpy
igc: replace deprecated strncpy with strscpy
drivers/net/ethernet/intel/e100.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 8 ++++----
drivers/net/ethernet/intel/i40e/i40e_ddp.c | 7 +++----
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
7 files changed, 12 insertions(+), 13 deletions(-)
---
base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
change-id: 20231010-netdev-replace-strncpy-resend-as-series-dee90d0c63bd
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On 10/10/2023 3:26 PM, Justin Stitt wrote: > Hi, > > This series aims to eliminate uses of strncpy() as it is a deprecated > interface [1] with many viable replacements available. > > Predominantly, strscpy() is the go-to replacement as it guarantees > NUL-termination on the destination buffer (which strncpy does not). With > that being said, I did not identify any buffer overread problems as the > size arguments were carefully measured to leave room for trailing > NUL-bytes. Nonetheless, we should favor more robust and less ambiguous > interfaces. > > Previously, each of these patches was sent individually at: > 1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/ > 2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/ > 3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/ > 4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/ > 5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/ > 6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/ > 7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/ > > Consider these dead as this series is their new home :) > > I found all these instances with: $ rg "strncpy\(" > > This series may collide in a not-so-nice way with [3]. This series can > go in after that one with a rebase. I'll send a v2 if necessary. > > [3]: https://lore.kernel.org/netdev/20231003183603.3887546-1-jesse.brandeburg@intel.com/ > > 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 > Signed-off-by: Justin Stitt <justinstitt@google.com> Thanks Justin for fixing all these! For the series: Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> PS: have you considered adding a script to scripts/coccinelle/api which might catch and try to fix future (ab)users of strncpy?
On Tue, Oct 10, 2023 at 4:19 PM Jesse Brandeburg <jesse.brandeburg@intel.com> wrote: > > On 10/10/2023 3:26 PM, Justin Stitt wrote: > > Hi, > > > > This series aims to eliminate uses of strncpy() as it is a deprecated > > interface [1] with many viable replacements available. > > > > Predominantly, strscpy() is the go-to replacement as it guarantees > > NUL-termination on the destination buffer (which strncpy does not). With > > that being said, I did not identify any buffer overread problems as the > > size arguments were carefully measured to leave room for trailing > > NUL-bytes. Nonetheless, we should favor more robust and less ambiguous > > interfaces. > > > > Previously, each of these patches was sent individually at: > > 1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/ > > 2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/ > > 3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/ > > 4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/ > > 5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/ > > 6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/ > > 7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/ > > > > Consider these dead as this series is their new home :) > > > > I found all these instances with: $ rg "strncpy\(" > > > > This series may collide in a not-so-nice way with [3]. This series can > > go in after that one with a rebase. I'll send a v2 if necessary. > > > > [3]: https://lore.kernel.org/netdev/20231003183603.3887546-1-jesse.brandeburg@intel.com/ > > > > 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 > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > Thanks Justin for fixing all these! > > For the series: > Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> > > PS: have you considered adding a script to scripts/coccinelle/api which > might catch and try to fix future (ab)users of strncpy? There is a checkpatch routine for it. Also, the docs are littered with aversions to strncpy. With that being said, I would not be opposed to adding more checks, though. Once I'm more caught up on all the outstanding strncpy uses, I'll look into adding some coccinelle support. > Thanks Justin
On Tue, Oct 10, 2023 at 04:22:44PM -0700, Justin Stitt wrote: > On Tue, Oct 10, 2023 at 4:19 PM Jesse Brandeburg > <jesse.brandeburg@intel.com> wrote: > > > > On 10/10/2023 3:26 PM, Justin Stitt wrote: > > > Hi, > > > > > > This series aims to eliminate uses of strncpy() as it is a deprecated > > > interface [1] with many viable replacements available. > > > > > > Predominantly, strscpy() is the go-to replacement as it guarantees > > > NUL-termination on the destination buffer (which strncpy does not). With > > > that being said, I did not identify any buffer overread problems as the > > > size arguments were carefully measured to leave room for trailing > > > NUL-bytes. Nonetheless, we should favor more robust and less ambiguous > > > interfaces. > > > > > > Previously, each of these patches was sent individually at: > > > 1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/ > > > 2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/ > > > 3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/ > > > 4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/ > > > 5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/ > > > 6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/ > > > 7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/ > > > > > > Consider these dead as this series is their new home :) > > > > > > I found all these instances with: $ rg "strncpy\(" > > > > > > This series may collide in a not-so-nice way with [3]. This series can > > > go in after that one with a rebase. I'll send a v2 if necessary. > > > > > > [3]: https://lore.kernel.org/netdev/20231003183603.3887546-1-jesse.brandeburg@intel.com/ > > > > > > 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 > > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > > > Thanks Justin for fixing all these! > > > > For the series: > > Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> > > > > PS: have you considered adding a script to scripts/coccinelle/api which > > might catch and try to fix future (ab)users of strncpy? > > There is a checkpatch routine for it. Also, the docs are littered with > aversions to strncpy. With that being said, I would not be opposed > to adding more checks, though. > > Once I'm more caught up on all the outstanding strncpy uses, > I'll look into adding some coccinelle support. Coccinelle for strncpy is difficult since each set of callers tends to need careful examination. But the good news here is that at the current rate, the kernel may be strncpy-free pretty soon. :)
On Tue, Oct 10, 2023 at 10:26:53PM +0000, Justin Stitt wrote: > Hi, > > This series aims to eliminate uses of strncpy() as it is a deprecated > interface [1] with many viable replacements available. > > Predominantly, strscpy() is the go-to replacement as it guarantees > NUL-termination on the destination buffer (which strncpy does not). With > that being said, I did not identify any buffer overread problems as the > size arguments were carefully measured to leave room for trailing > NUL-bytes. Nonetheless, we should favor more robust and less ambiguous > interfaces. > > Previously, each of these patches was sent individually at: > 1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/ > 2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/ > 3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/ > 4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/ > 5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/ > 6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/ > 7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/ > > Consider these dead as this series is their new home :) > > I found all these instances with: $ rg "strncpy\(" > > This series may collide in a not-so-nice way with [3]. This series can > go in after that one with a rebase. I'll send a v2 if necessary. > > [3]: https://lore.kernel.org/netdev/20231003183603.3887546-1-jesse.brandeburg@intel.com/ > > 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 > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Justin Stitt (7): > e100: replace deprecated strncpy with strscpy > e1000: replace deprecated strncpy with strscpy > fm10k: replace deprecated strncpy with strscpy > i40e: use scnprintf over strncpy+strncat > igb: replace deprecated strncpy with strscpy > igbvf: replace deprecated strncpy with strscpy > igc: replace deprecated strncpy with strscpy These all look good to me. Thanks for the careful analysis! Reviewed-by: Kees Cook <keescook@chromium.org> -Kees
On 10/10/2023 3:26 PM, Justin Stitt wrote: > Hi, > > This series aims to eliminate uses of strncpy() as it is a deprecated > interface [1] with many viable replacements available. > > Predominantly, strscpy() is the go-to replacement as it guarantees > NUL-termination on the destination buffer (which strncpy does not). With > that being said, I did not identify any buffer overread problems as the > size arguments were carefully measured to leave room for trailing > NUL-bytes. Nonetheless, we should favor more robust and less ambiguous > interfaces. > > Previously, each of these patches was sent individually at: > 1) https://lore.kernel.org/all/20231009-strncpy-drivers-net-ethernet-intel-e100-c-v1-1-ca0ff96868a3@google.com/ > 2) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-e1000-e1000_main-c-v1-1-b1d64581f983@google.com/ > 3) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-fm10k-fm10k_ethtool-c-v1-1-dbdc4570c5a6@google.com/ > 4) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-i40e-i40e_ddp-c-v1-1-f01a23394eab@google.com/ > 5) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igb-igb_main-c-v1-1-d796234a8abf@google.com/ > 6) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igbvf-netdev-c-v1-1-69ccfb2c2aa5@google.com/ > 7) https://lore.kernel.org/all/20231010-strncpy-drivers-net-ethernet-intel-igc-igc_main-c-v1-1-f1f507ecc476@google.com/ > > Consider these dead as this series is their new home :) > > I found all these instances with: $ rg "strncpy\(" > > This series may collide in a not-so-nice way with [3]. This series can > go in after that one with a rebase. I'll send a v2 if necessary. > I'm working to apply these to the Intel Wired LAN dev-queue now, and I'll see how bad it is. I will ping you if I need a rebased version. Thanks, Jake