Message ID | 20230727-sound-soc-codecs-v1-1-562fa2836bf4@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp81091vqg; Thu, 27 Jul 2023 16:51:22 -0700 (PDT) X-Google-Smtp-Source: APBJJlG/3sQ1kFeX3WMiuXfsjfVZHGVJX5EEcO7RGa/sBinJnDbBkKxKSdJeNQ45iNvA+lQ5VVk0 X-Received: by 2002:a17:902:b206:b0:1b9:d335:2216 with SMTP id t6-20020a170902b20600b001b9d3352216mr82105plr.20.1690501881993; Thu, 27 Jul 2023 16:51:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690501881; cv=none; d=google.com; s=arc-20160816; b=KusJ456zQ+7kL34APhUeBHVNJ9e8EuzpOQmruAohiS05UHfY2z3gWnN2sX/IODyP5k 4mhPPFtoopTDDwI2BU5GuEQ9ju+v2KpAwhxu0zrzsBDInUCEVF0paagtRfNZJcogvaTU 7xPMJoLorwMyFdOihOQA7T2onCldj4hLMW/ZTWqIdOR7EhFHSexnq/beU4sC9uhVgDNj RvyWaXvupNy+5yV/2epcc3Hq4x6F+6+6YbqwZpglBjIduwTw3kTdR1y2SzvaQuuSRpCZ bjjJ8cAryY0ammS0HKWh5wloy656tMcPIsWP2hV+zGwcOmj7O+TusMVzZwbK6BX0kAmB 1eyQ== 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=+xSxR3hp/I+0TJm3Gw1q3yDgLZR8du1mEjkS4CS9C3Y=; fh=cXliqg7Yd9wBQuvVOWDg7TSWRKXc/OP6eY6s7p/DU/s=; b=e6tF+Pm0r8K7oeQHEIvfQqiiSWBe3nyn9bsunlo8D0RpfN79R6xtF3QMlCDVa6gO4z m4dB3fzWCr94IFnYpUDzoP/W35/H6bOOGqMLvydFu8CjVrUWsfqxaSKKHhVfhwevpQwd d0PbhAIq9MQK+4/nHdDyg+dxjfoJbiLqXSoz8BoGJokOrKBfSwyEzpkV5ghQ5+Al/xeP o7qPGldl34fZJexZljamOv9UDl/BozJQrQ6Bkwn8KLo+bbTtB/LjUIUCTuLpZScJScKV OYgTy0VyuA6qlzgDch4ob014W5LxPXzDZ/RmZ6R+pnUtrLp5EJuQ4zeETeQd36p8d4V2 98pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=3p4mB6hS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o15-20020a170902d4cf00b001bb829d888dsi1986347plg.502.2023.07.27.16.51.09; Thu, 27 Jul 2023 16:51:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=3p4mB6hS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232861AbjG0WqS (ORCPT <rfc822;kloczko.tomasz@gmail.com> + 99 others); Thu, 27 Jul 2023 18:46:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229804AbjG0WqQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Jul 2023 18:46:16 -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 B58881BC3 for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 15:46:15 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-57320c10635so14862037b3.3 for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 15:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690497975; x=1691102775; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=+xSxR3hp/I+0TJm3Gw1q3yDgLZR8du1mEjkS4CS9C3Y=; b=3p4mB6hS4bB4DjFvuA8AjBwm5q5y+9Rzo3bKtgHjsDBsRvfkB/zxRokoM6g5pNE/r/ ZnvKnqADVXicY1zIdf1mIprFzlLZImIXH/CI0gtSf2ESS1Z/gZYWL+ArRYrb1YIZUMSD mqlsU25BuAOrvimQaJpZ08nOy4tHf6aQQSFHSU/YU6HpRljTxIg5nDzc51mMJc3On4pJ 64Vx2T9bnQutSKVxTtf0+xyW6SO/QUumDNILCURJWyNR1tewKdbLlTqGU9Cju7temypD L90tLrBo5GwqkwwwM0PC2+/H8f8qPtaM/j9HpULrmpfBJfIF9O2PBwZxWbEpTb/MOFCA 2aXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690497975; x=1691102775; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+xSxR3hp/I+0TJm3Gw1q3yDgLZR8du1mEjkS4CS9C3Y=; b=ioLq1RxQOf2HuZ7NRE9ynIoPx5P+iU9jNO0x9EjTsFcqgqM7ogzEMM5pPyEWVo9bVr BLPZGa9AANP3ZC2jZ7FgWAOjNfS0HOXvcDTpjaqQvbBFRWQB/Y1yXy2z7GcA1pe3I0Kx IUkqFsxulhQWb/VEhJ/qfC9tzXWz+7TCgWQ28jAjwD5bVAOsuFxmZ4O/Zgr01R7yWEgA BuQ9rR1c8gOw5UGKUbhmrZCCKVM0L465u1fdQKQl02Y1AuOuD0rUhpOBZvdPDqpLVBxg n0lnMOSwX4erQ5ifL0CpUlu3HPGJ50MSfybNSnrKywID8pYJriAD2E8xSuIKOGgPPTVI otDg== X-Gm-Message-State: ABy/qLYh6c5mUFmAxfXi1S5A/xLmaBIt6geUv1KEzlDnRrQtPXtqNhdt LHlwdv9Qj4cf6jZfhonvxVfbwbfolblUcPByZA== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:c58a:0:b0:d07:9d79:881c with SMTP id v132-20020a25c58a000000b00d079d79881cmr4ybe.11.1690497974749; Thu, 27 Jul 2023 15:46:14 -0700 (PDT) Date: Thu, 27 Jul 2023 22:46:13 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIALTzwmQC/x2MywqAIBAAfyX2nGD2kPqV6GDrVnvRcCkC6d+TL gNzmMkglJgEpipDopuFYyjS1BXg4cJOin1xMNq02hqrJF7BF6LC6AlFjZ3dcB37dnAWSnYm2vj 5l/Pyvh9K+aHLYgAAAA== X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1690497974; l=2418; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=bZgCYDFF558H9+uGABOoX1/6Falrihq1b+s55TkP1Rc=; b=RXhH5b4I6Sx8dSLpV7dWRHWahWzUnLIfmT5bv+HNz20DE0PdQ7UaHD8k8TSZLqjCeBJjEBK26 QNpKX4HQNG5ANdl4Q781Tn39kh8DTU+nTEgSo6JdYZ3svnd/iWTQW6q X-Mailer: b4 0.12.3 Message-ID: <20230727-sound-soc-codecs-v1-1-562fa2836bf4@google.com> Subject: [PATCH] ASoC: 88pm860x: refactor deprecated strncpy From: Justin Stitt <justinstitt@google.com> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772619701618751150 X-GMAIL-MSGID: 1772619701618751150 |
Series |
ASoC: 88pm860x: refactor deprecated strncpy
|
|
Commit Message
Justin Stitt
July 27, 2023, 10:46 p.m. UTC
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ always the case for `strncpy`!
In this case, though, there was care taken to ensure that the
destination buffer would be NUL-terminated. The destination buffer is
zero-initialized and each `pm860x->name[i]` has a size of
`MAX_NAME_LENGTH + 1`. This means that there is unlikely to be a bug
here.
However, in an attempt to eliminate the usage of the `strncpy` API as
well as disambiguate implementations, replacements such as: `strscpy`,
`strscpy_pad`, `strtomem` and `strtomem_pad` should be preferred.
We are able to eliminate the need for `len + 1` since `strscpy`
guarantees NUL-termination for its destination buffer as per its
implementation [3]:
| /* Hit buffer length without finding a NUL; force NUL-termination. */
| if (res)
| dest[res-1] = '\0';
[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
[3]: https://elixir.bootlin.com/linux/v6.3/source/lib/string.c#L183
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
sound/soc/codecs/88pm860x-codec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 57012c57536f8814dec92e74197ee96c3498d24e
change-id: 20230727-sound-soc-codecs-947fcb9536a7
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Thu, 27 Jul 2023 22:46:13 +0000, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > A suitable replacement is `strscpy` [2] due to the fact that it > guarantees NUL-termination on its destination buffer argument which is > _not_ always the case for `strncpy`! > > In this case, though, there was care taken to ensure that the > destination buffer would be NUL-terminated. The destination buffer is > zero-initialized and each `pm860x->name[i]` has a size of > `MAX_NAME_LENGTH + 1`. This means that there is unlikely to be a bug > here. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: 88pm860x: refactor deprecated strncpy commit: a9a65b87a5553a4ecabad7093ef6a1088bb71b88 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Thu, Jul 27, 2023 at 10:46:13PM +0000, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > A suitable replacement is `strscpy` [2] due to the fact that it > guarantees NUL-termination on its destination buffer argument which is > _not_ always the case for `strncpy`! > > In this case, though, there was care taken to ensure that the > destination buffer would be NUL-terminated. The destination buffer is > zero-initialized and each `pm860x->name[i]` has a size of > `MAX_NAME_LENGTH + 1`. This means that there is unlikely to be a bug > here. > > However, in an attempt to eliminate the usage of the `strncpy` API as > well as disambiguate implementations, replacements such as: `strscpy`, > `strscpy_pad`, `strtomem` and `strtomem_pad` should be preferred. > > We are able to eliminate the need for `len + 1` since `strscpy` > guarantees NUL-termination for its destination buffer as per its > implementation [3]: > > | /* Hit buffer length without finding a NUL; force NUL-termination. */ > | if (res) > | dest[res-1] = '\0'; > > [1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > [2]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html > [3]: https://elixir.bootlin.com/linux/v6.3/source/lib/string.c#L183 > > Link: https://github.com/KSPP/linux/issues/90 > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > sound/soc/codecs/88pm860x-codec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/codecs/88pm860x-codec.c b/sound/soc/codecs/88pm860x-codec.c > index 3574c68e0dda..d99b674d574b 100644 > --- a/sound/soc/codecs/88pm860x-codec.c > +++ b/sound/soc/codecs/88pm860x-codec.c > @@ -143,7 +143,7 @@ struct pm860x_priv { > struct pm860x_det det; > > int irq[4]; > - unsigned char name[4][MAX_NAME_LEN+1]; > + unsigned char name[4][MAX_NAME_LEN]; > }; > > /* -9450dB to 0dB in 150dB steps ( mute instead of -9450dB) */ > @@ -1373,7 +1373,7 @@ static int pm860x_codec_probe(struct platform_device *pdev) > return -EINVAL; > } > pm860x->irq[i] = res->start + chip->irq_base; > - strncpy(pm860x->name[i], res->name, MAX_NAME_LEN); > + strscpy(pm860x->name[i], res->name, MAX_NAME_LEN); res->name is (perhaps) unbounded in length: struct resource { ... const char *name; ... }; So reducing struct pm860x_priv::name's size _might_ have a user-visible effect, but probably not. Reviewed-by: Kees Cook <keescook@chromium.org> -Kees
diff --git a/sound/soc/codecs/88pm860x-codec.c b/sound/soc/codecs/88pm860x-codec.c index 3574c68e0dda..d99b674d574b 100644 --- a/sound/soc/codecs/88pm860x-codec.c +++ b/sound/soc/codecs/88pm860x-codec.c @@ -143,7 +143,7 @@ struct pm860x_priv { struct pm860x_det det; int irq[4]; - unsigned char name[4][MAX_NAME_LEN+1]; + unsigned char name[4][MAX_NAME_LEN]; }; /* -9450dB to 0dB in 150dB steps ( mute instead of -9450dB) */ @@ -1373,7 +1373,7 @@ static int pm860x_codec_probe(struct platform_device *pdev) return -EINVAL; } pm860x->irq[i] = res->start + chip->irq_base; - strncpy(pm860x->name[i], res->name, MAX_NAME_LEN); + strscpy(pm860x->name[i], res->name, MAX_NAME_LEN); } ret = devm_snd_soc_register_component(&pdev->dev,