linux-kernel - [BUG] Crash on named histogram trigger with invalid onmax variable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP4=nvTsxjckSBTz=Oe_UYh8keD9_sZC4i++4h72mJLic4_W4A@mail.gmail.com>
Date: Mon, 24 Feb 2025 16:22:39 +0100
From: Tomas Glozar <tglozar@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>
Cc: linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [BUG] Crash on named histogram trigger with invalid onmax variable

Dear maintainers and linux-trace-kernel,

I stumbled upon a bug in the histogram trigger implementation, where a
named histogram trigger with invalid onmax variable does not get
unregistered properly in the error path, and a subsequent access to
the same trigger file leads to kernel panic.

The issue reproduces on 6.14.0-rc4 with these commands (works with any
trace event):

$ cd /sys/kernel/tracing/events/rcu/rcu_callback
$ echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger
bash: echo: write error: Invalid argument
$ echo 'hist:name=bad:keys=common_pid' > trigger

which leads to the panic:

BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 UID: 0 PID: 2187 Comm: hist_panic_repr Kdump: loaded Not
tainted 6.14.0-rc4 #10
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41
04/01/2014
RIP: 0010:strcmp+0x10/0x30
...
Call Trace:
 <TASK>
 ? __die+0x24/0x70
 ? page_fault_oops+0x75/0x170
 ? exc_page_fault+0x70/0x160
 ? asm_exc_page_fault+0x26/0x30
 ? strcmp+0x10/0x30
 find_named_trigger+0x4a/0x70
 hist_register_trigger+0x3e/0x320
 event_hist_trigger_parse+0x520/0xa80
 trigger_process_regex+0xbc/0x110
 event_trigger_write+0x79/0xe0
 vfs_write+0xf7/0x420
 ? do_syscall_64+0x89/0x160
 ? syscall_exit_to_user_mode_prepare+0x154/0x190
 ksys_write+0x66/0xe0
 do_syscall_64+0x7d/0x160
 ? syscall_exit_to_user_mode_prepare+0x154/0x190
 ? syscall_exit_to_user_mode+0x32/0x1b0
 ? filp_flush+0x72/0x80
 ? filp_close+0x1f/0x30
 ? do_dup2+0xae/0x150
 ? ksys_dup3+0x65/0xf0
 ? syscall_exit_to_user_mode_prepare+0x154/0x190
 ? syscall_exit_to_user_mode+0x32/0x1b0
 ? clear_bhb_loop+0x25/0x80
 ? clear_bhb_loop+0x25/0x80
 ? clear_bhb_loop+0x25/0x80
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Further investigation revealed that hist_unregister_trigger called in
the out_unreg path in event_hist_trigger_parse (which, by the way,
accidentally passes glob+1 instead of glob; it doesn't matter only
because it is unused) does not find the trigger, and, thus, does not
free it and remove it from the named_triggers list.

Subsequent calls to find_named_trigger then finds the freed
hist_trigger_data, tries to compare against it for name and crashes
the kernel.

I'm not familiar with the trigger implementation. Do you have any
ideas on why the hist_unregister_trigger fails and/or a fix?

Thank you.

Tomas