linux-kernel - Re: [PATCH v2] tracing: Add test for user space strings when filtering on string pointers

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, 10 Jan 2022 19:21:04 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Pingfan Liu <kernelfans@...il.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH v2] tracing: Add test for user space strings when
 filtering on  string pointers

On Mon, 10 Jan 2022 22:03:20 +0000
David Laight <David.Laight@...LAB.COM> wrote:

> > Only root has access to the information read here. All tracing requires
> > root or those explicitly given access to the tracing data, which pretty
> > much allows all access to kernel internals (including all memory). So
> > nothing to worry about here ;-)  
> 
> Is this filtering trace using a filename passed to a system call by a user program?
> In which case a user program can set up a system call that normally fails
> (because the copy_from_user() errors) but if root tries to run a system
> call event trace on that process can read arbitrary addresses and
> thus crash the system?
> 
> While unlikely root might be persuaded to try to run the trace.

Yes. That's exactly what the code does today, and why it's a bug.

This patch instead uses copy_from_user_nofault/copy_from_kernel_nofault and
copies it into a temp buffer and then compares against that.

If a user passes in a crazy pointer, the copy_from_user/kernel_nofault()
will not read it, and the filter simply fails to match. Nothing bad will
happen.

-- Steve