From: Kees Cook <keescook@chromium.org>
To: Justin Stitt <justinstitt@google.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: 88pm860x: refactor deprecated strncpy
Date: Fri, 28 Jul 2023 14:05:02 -0700 [thread overview]
Message-ID: <202307281205.175FD2FC@keescook> (raw)
In-Reply-To: <20230727-sound-soc-codecs-v1-1-562fa2836bf4@google.com>
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
--
Kees Cook
prev parent reply other threads:[~2023-07-28 21:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 22:46 [PATCH] ASoC: 88pm860x: refactor deprecated strncpy Justin Stitt
2023-07-28 16:35 ` Mark Brown
2023-07-28 21:05 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202307281205.175FD2FC@keescook \
--to=keescook@chromium.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=justinstitt@google.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.