public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Justin Stitt <justinstitt@google.com>
Cc: Stuart Yoder <stuyoder@gmail.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] bus: fsl-mc: refactor deprecated strncpy
Date: Thu, 14 Sep 2023 20:36:15 -0700	[thread overview]
Message-ID: <202309142034.2B1DC7DE51@keescook> (raw)
In-Reply-To: <20230912-strncpy-drivers-bus-fsl-mc-dprc-c-v1-1-cdb56aa3f4f4@google.com>

On Tue, Sep 12, 2023 at 10:52:04PM +0000, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
> 
> We need to prefer more robust and less ambiguous string interfaces.
> 
> `obj_desc->(type|label)` are expected to be NUL-terminated strings as
> per "include/linux/fsl/mc.h +143"
> | ...
> |  * struct fsl_mc_obj_desc - Object descriptor
> |  * @type: Type of object: NULL terminated string
> | ...
> 
> It seems `cmd_params->obj_type` is also expected to be a NUL-terminated string.
> 
> A suitable replacement is `strscpy_pad` due to the fact that it
> guarantees NUL-termination on the destination buffer whilst keeping the
> NUL-padding behavior that `strncpy` provides.

I see evidence that %NUL padding isn't needed, like this:

                      /*
                       * Mark the obj entry as "invalid", by using the
                       * empty string as obj type:
                       */
                      obj_desc->type[0] = '\0';

but there's little harm in being conservative and leaving the padding
in.

> 
> Padding may not strictly be necessary but let's opt to keep it as this
> ensures no functional change.
> 
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
> 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>
> ---
> Note: build-tested
> ---
>  drivers/bus/fsl-mc/dprc.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index d129338b8bc0..dd1b5c0fb7e2 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -450,10 +450,8 @@ int dprc_get_obj(struct fsl_mc_io *mc_io,
>  	obj_desc->ver_major = le16_to_cpu(rsp_params->version_major);
>  	obj_desc->ver_minor = le16_to_cpu(rsp_params->version_minor);
>  	obj_desc->flags = le16_to_cpu(rsp_params->flags);
> -	strncpy(obj_desc->type, rsp_params->type, 16);
> -	obj_desc->type[15] = '\0';
> -	strncpy(obj_desc->label, rsp_params->label, 16);
> -	obj_desc->label[15] = '\0';
> +	strscpy_pad(obj_desc->type, rsp_params->type, 16);
> +	strscpy_pad(obj_desc->label, rsp_params->label, 16);

I really don't like all the open-coded sizes, but yeah, okay, it's not
technically wrong. :)

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees

>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(dprc_get_obj);
> @@ -491,8 +489,7 @@ int dprc_set_obj_irq(struct fsl_mc_io *mc_io,
>  	cmd_params->irq_addr = cpu_to_le64(irq_cfg->paddr);
>  	cmd_params->irq_num = cpu_to_le32(irq_cfg->irq_num);
>  	cmd_params->obj_id = cpu_to_le32(obj_id);
> -	strncpy(cmd_params->obj_type, obj_type, 16);
> -	cmd_params->obj_type[15] = '\0';
> +	strscpy_pad(cmd_params->obj_type, obj_type, 16);
>  
>  	/* send command to mc*/
>  	return mc_send_command(mc_io, &cmd);
> @@ -564,8 +561,7 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
>  	cmd_params = (struct dprc_cmd_get_obj_region *)cmd.params;
>  	cmd_params->obj_id = cpu_to_le32(obj_id);
>  	cmd_params->region_index = region_index;
> -	strncpy(cmd_params->obj_type, obj_type, 16);
> -	cmd_params->obj_type[15] = '\0';
> +	strscpy_pad(cmd_params->obj_type, obj_type, 16);
>  
>  	/* send command to mc*/
>  	err = mc_send_command(mc_io, &cmd);
> 
> ---
> base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> change-id: 20230912-strncpy-drivers-bus-fsl-mc-dprc-c-bc7d818386ec
> 
> Best regards,
> --
> Justin Stitt <justinstitt@google.com>
> 

-- 
Kees Cook

  reply	other threads:[~2023-09-15  3:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 22:52 [PATCH] bus: fsl-mc: refactor deprecated strncpy Justin Stitt
2023-09-15  3:36 ` Kees Cook [this message]
2023-09-29 18:43 ` Kees Cook

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=202309142034.2B1DC7DE51@keescook \
    --to=keescook@chromium.org \
    --cc=justinstitt@google.com \
    --cc=laurentiu.tudor@nxp.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stuyoder@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox