linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
	Thorsten Blum <thorsten.blum@linux.dev>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	David Laight <david.laight.linux@gmail.com>
Subject: Re: [PATCH] unwind: Show that entries of struct unwind_cache is not bound by nr_entries
Date: Mon, 17 Nov 2025 13:28:59 -0800	[thread overview]
Message-ID: <202511171303.1623D77@keescook> (raw)
In-Reply-To: <20251114121352.35108fb8@gandalf.local.home>

On Fri, Nov 14, 2025 at 12:13:52PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> 
> The structure unwind_cache has:
> 
> struct unwind_cache {
> 	unsigned long		unwind_completed;
> 	unsigned int		nr_entries;
> 	unsigned long		entries[];
> };
> 
> Which triggers lots of scripts to convert this to:
> 
> struct unwind_cache {
> 	unsigned long		unwind_completed;
> 	unsigned int		nr_entries;
> 	unsigned long		entries[] __counted_by(nr_entries);
> };
> 
> But that is incorrect. The structure is created via:
> 
>  #define UNWIND_MAX_ENTRIES					\
> 	((SZ_4K - sizeof(struct unwind_cache)) / sizeof(long))
> 
>  info->cache = kzalloc(struct_size(cache, entries, UNWIND_MAX_ENTRIES), GFP_KERNEL);
> 
> Where the size of entries is determined by the size of the rest of the
> structure subtracted from 4K. But because the size of entries has a
> dependency on the structure itself, it can't be used to define it.
> 
> The entries are filled by another function that returns how many entries it
> added and that is what nr_entries gets set to. This would most definitely
> trigger a false-positive out-of-bounds bug if the __counted_by() was added.

Just so I'm clear: "nr_entries" shows how many _valid_ entries exist in
entries[] (even if more are allocated there)? (Wouldn't you still want to
know if something tried to access an invalid entry? But I digress...)

> To stop scripts from thinking this needs a counted_by(), move the
> UNWIND_MAX_ENTRIES macro to the header, and add a comment in the entries
> size:
> 
> 	unsigned long		entries[ /* UNWIND_MAX_ENTRIES */ ];

This doesn't solve the problem that we've hidden the actual size of the
(fixed size!) object from the compiler, forcing it to avoid doing bounds
checking on it.

The problem is that the non-"entries" portion of the struct doesn't have
a "name" associated with it at declaration time, but we have a solution
for that already: struct_group. I would propose this form instead, which
requires no changes to how unwind_cache is used, and allows for the true
size of the "entries" array to be exposed to the compiler (and allows
for "normal" methods of finding the max entries):

struct unwind_cache {
	struct_group_tagged(unwind_cache_hdr, hdr,
		unsigned long unwind_completed;
		unsigned int  nr_entries;
	);
	unsigned long         entries[(SZ_4K - sizeof(struct unwind_cache_hdr)) / sizeof(long)];
};

#define UNWIND_MAX_ENTRIES ARRAY_SIZE(((struct unwind_cache*)NULL)->entries)

And this checks out for me:

UNWIND_MAX_ENTRIES:510
sizeof(struct unwind_cache):4096

No hiding things from the compiler, and you can treat "entries" like a
real array (since it is one now).

-Kees

-- 
Kees Cook

      reply	other threads:[~2025-11-17 21:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14 17:13 [PATCH] unwind: Show that entries of struct unwind_cache is not bound by nr_entries Steven Rostedt
2025-11-17 21:28 ` 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=202511171303.1623D77@keescook \
    --to=kees@kernel.org \
    --cc=david.laight.linux@gmail.com \
    --cc=gustavoars@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).