All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Thorsten Blum <thorsten.blum@linux.dev>
Cc: Peter Rosin <peda@axentia.se>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [RESEND PATCH] mux: Convert mux_control_ops to a flex array member in mux_chip
Date: Mon, 3 Mar 2025 10:44:20 -0800	[thread overview]
Message-ID: <202503031040.223DEF2781@keescook> (raw)
In-Reply-To: <20250302230220.245739-3-thorsten.blum@linux.dev>

On Mon, Mar 03, 2025 at 12:02:22AM +0100, Thorsten Blum wrote:
> Convert mux_control_ops to a flexible array member at the end of the
> mux_chip struct and add the __counted_by() compiler attribute to
> improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
> CONFIG_FORTIFY_SOURCE.
> 
> Use struct_size() to calculate the number of bytes to allocate for a new
> mux chip and to remove the following Coccinelle/coccicheck warning:
> 
>   WARNING: Use struct_size
> 
> Use size_add() to safely add any extra bytes.
> 
> Compile-tested only.

I believe this will fail at runtime. Note that sizeof_priv follows the
allocation, so at the very least, you'd need to update:

static inline void *mux_chip_priv(struct mux_chip *mux_chip)
{
        return &mux_chip->mux[mux_chip->controllers];
}

to not use the mux array itself as a location reference because it will
be seen as out of bounds.

To deal with this, the location will need to be calculated using
mux_chip as the base, not mux_chip->mux as the base. For example, see
commit 838ae9f45c4e ("nouveau/gsp: Avoid addressing beyond end of rpc->entries")

-Kees

> 
> Link: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  drivers/mux/core.c         | 7 +++----
>  include/linux/mux/driver.h | 4 ++--
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> index 02be4ba37257..a3840fe0995f 100644
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -98,13 +98,12 @@ struct mux_chip *mux_chip_alloc(struct device *dev,
>  	if (WARN_ON(!dev || !controllers))
>  		return ERR_PTR(-EINVAL);
>  
> -	mux_chip = kzalloc(sizeof(*mux_chip) +
> -			   controllers * sizeof(*mux_chip->mux) +
> -			   sizeof_priv, GFP_KERNEL);
> +	mux_chip = kzalloc(size_add(struct_size(mux_chip, mux, controllers),
> +				    sizeof_priv),
> +			   GFP_KERNEL);
>  	if (!mux_chip)
>  		return ERR_PTR(-ENOMEM);
>  
> -	mux_chip->mux = (struct mux_control *)(mux_chip + 1);
>  	mux_chip->dev.class = &mux_class;
>  	mux_chip->dev.type = &mux_type;
>  	mux_chip->dev.parent = dev;
> diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
> index 18824064f8c0..e58e59354e23 100644
> --- a/include/linux/mux/driver.h
> +++ b/include/linux/mux/driver.h
> @@ -56,18 +56,18 @@ struct mux_control {
>  /**
>   * struct mux_chip -	Represents a chip holding mux controllers.
>   * @controllers:	Number of mux controllers handled by the chip.
> - * @mux:		Array of mux controllers that are handled.
>   * @dev:		Device structure.
>   * @id:			Used to identify the device internally.
>   * @ops:		Mux controller operations.
> + * @mux:		Array of mux controllers that are handled.
>   */
>  struct mux_chip {
>  	unsigned int controllers;
> -	struct mux_control *mux;
>  	struct device dev;
>  	int id;
>  
>  	const struct mux_control_ops *ops;
> +	struct mux_control mux[] __counted_by(controllers);
>  };
>  
>  #define to_mux_chip(x) container_of((x), struct mux_chip, dev)
> -- 
> 2.48.1
> 
> 

-- 
Kees Cook

  reply	other threads:[~2025-03-03 18:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-02 23:02 [RESEND PATCH] mux: Convert mux_control_ops to a flex array member in mux_chip Thorsten Blum
2025-03-03 18:44 ` Kees Cook [this message]
2025-03-04  8:58   ` Thorsten Blum
2025-03-05  4:57     ` Kees Cook
2025-03-05 17:31       ` Qing Zhao
2025-03-05 17:31       ` Qing Zhao
2025-03-05 22:42         ` Kees Cook
2025-03-07 11:32   ` Thorsten Blum
2025-04-07 18:20     ` Kees Cook
2025-04-13 12:42       ` Thorsten Blum
2025-04-29 11:55         ` Thorsten Blum
  -- strict thread matches above, loose matches on Subject: below --
2025-03-18 16:27 Thorsten Blum

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=202503031040.223DEF2781@keescook \
    --to=kees@kernel.org \
    --cc=gustavoars@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=thorsten.blum@linux.dev \
    /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.