linux-kernel - Re: [PATCH v4 02/10] user_events: Add minimal support for trace

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]

Date:   Mon, 8 Nov 2021 13:16:39 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 02/10] user_events: Add minimal support for
 trace_event into ftrace

On Mon, 8 Nov 2021 09:13:36 -0800
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> Does that mean the decoders in eprobes/histogram don't check event
> record sizes before accessing the data? Shouldn't that get fix
> centrally? That would mean a loaded module could do the same thing
> (user_events only works if the user has access to tracefs, so it's not
> like it's open to all users).

There's checks to make sure everything fits in eprobes and kprobes. If it
doesn't then the event is simply dropped.

For example, if you look at __eprobe_trace_func() in trace_eprobe.c, you'll
see that it calls get_eprobe_size(), which goes through and just reads what
it is about to accept. Then it reserves the amount of data on the ring
buffer, and then calls store_trace_args() which also passes in the size
that it found, in case things change. If it's too big, it only records what
it originally intended.

-- Steve