linux-kernel - [PATCH -next 1/2] ftrace: Remove unnecessary free_ftrace_hash in ftrace_regex

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250813023044.2121943-2-wutengda@huaweicloud.com>
Date: Wed, 13 Aug 2025 02:30:43 +0000
From: Tengda Wu <wutengda@...weicloud.com>
To: Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-trace-kernel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Tengda Wu <wutengda@...weicloud.com>
Subject: [PATCH -next 1/2] ftrace: Remove unnecessary free_ftrace_hash in ftrace_regex_open

When reading set_ftrace_{notrace,filter} files, the ftrace_regex_open()
function incorrectly frees iter->hash when seq_open fails. This is
problematic because iter->hash points to the global {notrace,filter}_hash,
and the reading process freeing it would cause errors when other processes
access this memory.

The specific scenario occurs when:
1. {notrace,filter}_hash gets freed by a reader
2. Another process attempts to append something to the file
3. alloc_and_copy_ftrace_hash() tries to duplicate the freed {notrace,filter}_hash
4. A use-after-free (UAF) occurs

[  146.788584] BUG: KASAN: slab-use-after-free in alloc_and_copy_ftrace_hash+0x4b4/0x4c0
[  146.790278] Read of size 8 at addr ffff88810fa20818 by task bash/163
[  146.791254]
[  146.792776] CPU: 3 UID: 0 PID: 163 Comm: bash Not tainted 6.16.0-next-20250808+ #13 PREEMPT(full)
[  146.793243] Call Trace:
[  146.793393]  <TASK>
[  146.793572]  dump_stack_lvl+0x55/0x70
[  146.793729]  print_report+0xcb/0x610
[  146.793777]  ? __virt_addr_valid+0x1e8/0x2e0
[  146.793818]  ? alloc_and_copy_ftrace_hash+0x4b4/0x4c0
[  146.793852]  kasan_report+0xb8/0xf0
[  146.793886]  ? alloc_and_copy_ftrace_hash+0x4b4/0x4c0
[  146.793928]  alloc_and_copy_ftrace_hash+0x4b4/0x4c0
[  146.793964]  ? mutex_lock+0x90/0xe0
[  146.794002]  ftrace_regex_open+0x61f/0xc80
[  146.794182]  do_dentry_open+0x44f/0x1110
[  146.794369]  vfs_open+0x79/0x350
[  146.794412]  path_openat+0x13fb/0x3ec0
[  146.794662]  do_filp_open+0x1d7/0x420
[  146.794874]  do_sys_openat2+0xd4/0x160
[  146.794976]  __x64_sys_openat+0x122/0x1e0
[  146.795078]  do_syscall_64+0x4d/0x1d0
[  146.795112]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

The free_ftrace_hash call is just unnecessary in this context since
we shouldn't free the global hash that we don't own. Remove this call
to fix the issue.

Fixes: c20489dad156 ("ftrace: Assign iter->hash to filter or notrace hashes on seq read")
Signed-off-by: Tengda Wu <wutengda@...weicloud.com>
---
 kernel/trace/ftrace.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 00b76d450a89..cade13595b08 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4680,7 +4680,6 @@ ftrace_regex_open(struct ftrace_ops *ops, int flag,
 			m->private = iter;
 		} else {
 			/* Failed */
-			free_ftrace_hash(iter->hash);
 			trace_parser_put(&iter->parser);
 		}
 	} else
-- 
2.34.1