public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thorsten Blum <thorsten.blum@linux.dev>
To: Kees Cook <kees@kernel.org>
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: Fri, 7 Mar 2025 12:32:07 +0100	[thread overview]
Message-ID: <785391F0-C381-47FE-89E7-6265F7761208@linux.dev> (raw)
In-Reply-To: <202503031040.223DEF2781@keescook>

On 3. Mar 2025, at 19:44, Kees Cook wrote:
> 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")

Since this should work and is well-defined C code according to [1][2],
could you give this patch another look or should I still change it and
submit a v2?

Thanks,
Thorsten

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
[2] https://github.com/llvm/llvm-project/issues/129951

  parent reply	other threads:[~2025-03-07 11:32 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
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 [this message]
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=785391F0-C381-47FE-89E7-6265F7761208@linux.dev \
    --to=thorsten.blum@linux.dev \
    --cc=gustavoars@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    /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