[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240128224054.0df489b8@rorschach.local.home>
Date: Sun, 28 Jan 2024 22:40:54 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, LKML <linux-kernel@...r.kernel.org>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>, Christian Brauner
<brauner@...nel.org>, Ajay Kaher <ajay.kaher@...adcom.com>, Geert
Uytterhoeven <geert@...ux-m68k.org>, linux-fsdevel
<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers
On Sun, 28 Jan 2024 21:32:49 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> # echo 'p:sched schedule' >> kprobe_events
> # ls events/kprobes
> enable filter sched timer
>
> # ls events/kprobes/sched/
> ls: reading directory 'events/kprobes/sched/': Invalid argument
>
> I have no access to the directory that was deleted and recreated.
Ah, this was because the final iput() does dentry->d_fsdata = NULL, and
in the lookup code I have:
mutex_lock(&eventfs_mutex);
ei = READ_ONCE(ti->private);
if (ei && ei->is_freed)
ei = NULL;
mutex_unlock(&eventfs_mutex);
if (!ei) {
printk("HELLO no ei\n");
goto out;
}
Where that printk() was triggering.
So at least it's not calling back into the tracing code ;-)
Interesting that it still did the lookup, even though it was already
referenced.
I'm still learning the internals of VFS.
Anyway, after keeping the d_fsdata untouched (not going to NULL), just
to see what would happen, I ran it again with KASAN and did trigger:
[ 106.255468] ==================================================================
[ 106.258400] BUG: KASAN: slab-use-after-free in tracing_open_file_tr+0x3a/0x120
[ 106.261228] Read of size 8 at addr ffff8881136f27b8 by task cat/868
[ 106.264506] CPU: 2 PID: 868 Comm: cat Not tainted 6.8.0-rc1-test-00008-gbee668990ac4-dirty #454
[ 106.267810] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 106.271337] Call Trace:
[ 106.272406] <TASK>
[ 106.273317] dump_stack_lvl+0x5c/0xc0
[ 106.274750] print_report+0xcf/0x670
[ 106.276173] ? __virt_addr_valid+0x15a/0x330
[ 106.278807] kasan_report+0xd8/0x110
[ 106.280172] ? tracing_open_file_tr+0x3a/0x120
[ 106.281745] ? tracing_open_file_tr+0x3a/0x120
[ 106.283343] tracing_open_file_tr+0x3a/0x120
[ 106.284887] do_dentry_open+0x3b7/0x950
[ 106.286284] ? __pfx_tracing_open_file_tr+0x10/0x10
[ 106.287992] path_openat+0xea8/0x11d0
That was with just these commands:
cd /sys/kernel/tracing/
echo 'p:sched schedule' >> /sys/kernel/tracing/kprobe_events
echo 'p:timer read_current_timer' >> kprobe_events
ls events/kprobes/
cat events/kprobes/sched/enable
ls events/kprobes/sched
echo '-:sched schedule' >> /sys/kernel/tracing/kprobe_events
ls events/kprobes/sched/enable
cat events/kprobes/sched/enable
BTW, the ls after the deletion returned:
# ls events/kprobes/sched/enable
events/kprobes/sched/enable
In a normal file system that would be equivalent to:
# mkdir events/kprobes/sched
# touch events/kprobes/sched/enable
# rm -rf events/kprobes/sched
# ls events/kprobes/sched/enable
events/kprobes/sched/enable
-- Steve
Powered by blists - more mailing lists