On Wed, May 20, 2026 at 6:28 PM Steven Rostedt <[email protected]> wrote:
>
> On Wed, 20 May 2026 15:00:30 -0700
> Rosen Penev <[email protected]> wrote:
>
> > Store ftrace hash buckets in the ftrace_hash allocation instead of
> > allocating the bucket array separately.
> >
> > This keeps the bucket storage tied to the hash lifetime and simplifies
> > the allocation and cleanup paths.
> >
> > Assisted-by: Codex:GPT-5.5
>
> I'll let the AI's duke it out!
>
> > Signed-off-by: Rosen Penev <[email protected]>
> > ---
> > kernel/trace/ftrace.c | 17 ++---------------
> > kernel/trace/trace.h | 2 +-
> > 2 files changed, 3 insertions(+), 16 deletions(-)
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index b2611de3f594..25a9dca290dd 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -1082,10 +1082,7 @@ struct ftrace_func_probe {
> > * it all the time. These are in a read only section such that if
> > * anyone does try to modify it, it will cause an exception.
> > */
> > -static const struct hlist_head empty_buckets[1];
> > -static const struct ftrace_hash empty_hash = {
> > - .buckets = (struct hlist_head *)empty_buckets,
> > -};
> > +static const struct ftrace_hash empty_hash = {};
> > #define EMPTY_HASH ((struct ftrace_hash *)&empty_hash)
>
>
> According to Sashiko:
> https://sashiko.dev/#/patchset/20260520220030.16887-1-rosenp%40gmail.com
>
> Could this conversion to a flexible array member cause an
> out-of-bounds read when iterating over the empty hash? Because
> empty_hash is now initialized as an empty struct, its flexible array
> member buckets has a size of 0. However, empty_hash.size_bits is 0,
> which means loop limits computing '1 << hash->size_bits' will
> evaluate to 1. If functions like
> prepare_direct_functions_for_ipmodify() iterate over a default
> EMPTY_HASH without checking ftrace_hash_empty(), they will attempt
> to read EMPTY_HASH->buckets[0]. This reads past the end of the
> struct into adjacent memory in the .rodata section. If that adjacent
> memory happens to be non-zero, the linked list loop could
> dereference it and cause a kernel panic. Prior to this patch,
> empty_buckets provided a safely zeroed array of size 1 to handle
> this single iteration.
Yeah this looks right. Might as well abandon.
>
> -- Steve
