* [PATCH] ftrace: Use flexible array for hash buckets
@ 2026-05-20 22:00 Rosen Penev
2026-05-21 1:28 ` Steven Rostedt
2026-05-22 8:45 ` kernel test robot
0 siblings, 2 replies; 4+ messages in thread
From: Rosen Penev @ 2026-05-20 22:00 UTC (permalink / raw)
To: linux-trace-kernel
Cc: Steven Rostedt, Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers,
open list:FUNCTION HOOKS (FTRACE)
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
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
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)
struct ftrace_ops global_ops = {
@@ -1295,7 +1292,6 @@ void free_ftrace_hash(struct ftrace_hash *hash)
if (!hash || hash == EMPTY_HASH)
return;
ftrace_hash_clear(hash);
- kfree(hash->buckets);
kfree(hash);
}
@@ -1333,20 +1329,11 @@ EXPORT_SYMBOL_GPL(ftrace_free_filter);
struct ftrace_hash *alloc_ftrace_hash(int size_bits)
{
struct ftrace_hash *hash;
- int size;
- hash = kzalloc_obj(*hash);
+ hash = kzalloc_flex(*hash, buckets, BIT(size_bits));
if (!hash)
return NULL;
- size = 1 << size_bits;
- hash->buckets = kzalloc_objs(*hash->buckets, size);
-
- if (!hash->buckets) {
- kfree(hash);
- return NULL;
- }
-
hash->size_bits = size_bits;
return hash;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 80fe152af1dd..5a3f81f17317 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1000,10 +1000,10 @@ enum {
struct ftrace_hash {
unsigned long size_bits;
- struct hlist_head *buckets;
unsigned long count;
unsigned long flags;
struct rcu_head rcu;
+ struct hlist_head buckets[];
};
struct ftrace_func_entry *
--
2.54.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] ftrace: Use flexible array for hash buckets
2026-05-20 22:00 [PATCH] ftrace: Use flexible array for hash buckets Rosen Penev
@ 2026-05-21 1:28 ` Steven Rostedt
2026-05-21 1:39 ` Rosen Penev
2026-05-22 8:45 ` kernel test robot
1 sibling, 1 reply; 4+ messages in thread
From: Steven Rostedt @ 2026-05-21 1:28 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, open list:FUNCTION HOOKS (FTRACE), sashiko-bot,
sashiko-reviews
On Wed, 20 May 2026 15:00:30 -0700
Rosen Penev <rosenp@gmail.com> 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 <rosenp@gmail.com>
> ---
> 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.
-- Steve
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] ftrace: Use flexible array for hash buckets
2026-05-21 1:28 ` Steven Rostedt
@ 2026-05-21 1:39 ` Rosen Penev
0 siblings, 0 replies; 4+ messages in thread
From: Rosen Penev @ 2026-05-21 1:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, open list:FUNCTION HOOKS (FTRACE), sashiko-bot,
sashiko-reviews
On Wed, May 20, 2026 at 6:28 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 20 May 2026 15:00:30 -0700
> Rosen Penev <rosenp@gmail.com> 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 <rosenp@gmail.com>
> > ---
> > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ftrace: Use flexible array for hash buckets
2026-05-20 22:00 [PATCH] ftrace: Use flexible array for hash buckets Rosen Penev
2026-05-21 1:28 ` Steven Rostedt
@ 2026-05-22 8:45 ` kernel test robot
1 sibling, 0 replies; 4+ messages in thread
From: kernel test robot @ 2026-05-22 8:45 UTC (permalink / raw)
To: Rosen Penev
Cc: oe-lkp, lkp, linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, oliver.sang
Hello,
kernel test robot noticed "BUG:KASAN:global-out-of-bounds_in_ftrace_find_rec_direct" on:
commit: 42ed22b1b4ae179c78e088477950eb1dd1dc9e90 ("[PATCH] ftrace: Use flexible array for hash buckets")
url: https://github.com/intel-lab-lkp/linux/commits/Rosen-Penev/ftrace-Use-flexible-array-for-hash-buckets/20260521-060312
base: https://git.kernel.org/cgit/linux/kernel/git/trace/linux-trace for-next
patch link: https://lore.kernel.org/all/20260520220030.16887-1-rosenp@gmail.com/
patch subject: [PATCH] ftrace: Use flexible array for hash buckets
in testcase: boot
config: x86_64-rhel-9.4-kunit
compiler: gcc-14
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605221023.2bcc5f10-lkp@intel.com
[ 9.849798][ T1] BUG: KASAN: global-out-of-bounds in ftrace_find_rec_direct (trace/ftrace.c:1172 (discriminator 2) trace/ftrace.c:2611 (discriminator 2))
[ 9.849798][ T1] Read of size 8 at addr ffffffff9675bd48 by task swapper/0/1
[ 9.849798][ T1]
[ 9.849798][ T1] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc3+ #1 PREEMPT(lazy)
[ 9.849798][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 9.849798][ T1] Call Trace:
[ 9.849798][ T1] <TASK>
[ 9.849798][ T1] dump_stack_lvl (dump_stack.c:94 dump_stack.c:120)
[ 9.849798][ T1] print_address_description+0x70/0x300
[ 9.849798][ T1] print_report (kasan/report.c:482)
[ 9.849798][ T1] ? __virt_addr_valid (linux/mmzone.h:2198 (discriminator 1) linux/mmzone.h:2280 (discriminator 1) x86/mm/physaddr.c:54 (discriminator 1))
[ 9.849798][ T1] ? ftrace_find_rec_direct (trace/ftrace.c:1172 (discriminator 2) trace/ftrace.c:2611 (discriminator 2))
[ 9.849798][ T1] kasan_report (kasan/report.c:595)
[ 9.849798][ T1] ? ftrace_find_rec_direct (trace/ftrace.c:1172 (discriminator 2) trace/ftrace.c:2611 (discriminator 2))
[ 9.849798][ T1] ? __pfx_trace_selftest_dynamic_test_func (??:?)
[ 9.849798][ T1] ftrace_find_rec_direct (trace/ftrace.c:1172 (discriminator 2) trace/ftrace.c:2611 (discriminator 2))
[ 9.849798][ T1] register_ftrace_direct (trace/ftrace.c:6057)
[ 9.849798][ T1] ? __pfx_ftrace_stub_direct_tramp (x86/kernel/ftrace_64.S:318)
[ 9.849798][ T1] trace_selftest_startup_function_graph (trace/trace_selftest.c:1139)
[ 9.849798][ T1] ? __pfx_trace_selftest_startup_function_graph (trace/trace_selftest.c:754)
[ 9.849798][ T1] run_tracer_selftest (trace/trace.c:1335)
[ 9.849798][ T1] register_tracer (trace/trace.c:1375 trace/trace.c:1492)
[ 9.849798][ T1] ? __pfx_init_graph_trace (trace/trace_functions_graph.c:1811)
[ 9.849798][ T1] do_one_initcall (main.c:1347)
[ 9.849798][ T1] ? __pfx_do_one_initcall (trace/events/initcall.h:10)
[ 9.849798][ T1] ? asm_sysvec_apic_timer_interrupt (x86/include/asm/idtentry.h:569)
[ 9.849798][ T1] ? ret_from_fork_asm (x86/entry/entry_64.S:245)
[ 9.849798][ T1] do_initcalls (main.c:1409 (discriminator 1) main.c:1425 (discriminator 1))
[ 9.849798][ T1] kernel_init_freeable (main.c:1445 main.c:1658)
[ 9.849798][ T1] ? __pfx_kernel_init_freeable (main.c:1626)
[ 9.849798][ T1] ? __pfx_schedule_timeout (??:?)
[ 9.849798][ T1] ? __pfx__raw_spin_lock_irq (locking/spinlock.c:183)
[ 9.849798][ T1] ? __pfx_kernel_init (main.c:717)
[ 9.849798][ T1] kernel_init (main.c:1548)
[ 9.849798][ T1] ? __pfx_kernel_init (main.c:717)
[ 9.849798][ T1] ret_from_fork (x86/kernel/process.c:158)
[ 9.849798][ T1] ? __pfx_ret_from_fork (x86/include/asm/entry-common.h:54)
[ 9.849798][ T1] ? switch_fpu (linux/instrumented.h:82 asm-generic/bitops/instrumented-non-atomic.h:141 linux/thread_info.h:133 linux/sched.h:2066 x86/include/asm/fpu/sched.h:34)
[ 9.849798][ T1] ? __switch_to (x86/kernel/process_64.c:619)
[ 9.849798][ T1] ? __switch_to_asm (x86/entry/entry_64.S:206)
[ 9.849798][ T1] ? __pfx_kernel_init (main.c:717)
[ 9.849798][ T1] ret_from_fork_asm (x86/entry/entry_64.S:245)
[ 9.849798][ T1] </TASK>
[ 9.849798][ T1]
[ 9.849798][ T1] The buggy address belongs to the variable:
[ 9.849798][ T1] empty_hash+0x28/0xa0
[ 9.849798][ T1]
[ 9.849798][ T1] The buggy address belongs to the physical page:
[ 9.849798][ T1] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x77d95b
[ 9.849798][ T1] flags: 0x17ffffc0002000(reserved|node=0|zone=2|lastcpupid=0x1fffff)
[ 9.849798][ T1] raw: 0017ffffc0002000 ffffea001df656c8 ffffea001df656c8 0000000000000000
[ 9.849798][ T1] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 9.849798][ T1] page dumped because: kasan: bad access detected
[ 9.849798][ T1]
[ 9.849798][ T1] Memory state around the buggy address:
[ 9.849798][ T1] ffffffff9675bc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.849798][ T1] ffffffff9675bc80: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
[ 9.849798][ T1] >ffffffff9675bd00: f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9
[ 9.849798][ T1] ^
[ 9.849798][ T1] ffffffff9675bd80: 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
[ 9.849798][ T1] ffffffff9675be00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 9.849798][ T1] ==================================================================
[ 9.904835][ T1] Disabling lock debugging due to kernel taint
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260522/202605221023.2bcc5f10-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-22 8:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-20 22:00 [PATCH] ftrace: Use flexible array for hash buckets Rosen Penev
2026-05-21 1:28 ` Steven Rostedt
2026-05-21 1:39 ` Rosen Penev
2026-05-22 8:45 ` kernel test robot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox