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 22:03:20 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Steven Rostedt' <rostedt@...dmis.org>
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

From: Steven Rostedt
> Sent: 10 January 2022 17:25
> 
> On Mon, 10 Jan 2022 17:11:52 +0000
> David Laight <David.Laight@...LAB.COM> wrote:
> 
> > From: Steven Rostedt
> > > Sent: 10 January 2022 16:56
> > >
> > > From: Steven Rostedt <rostedt@...dmis.org>
> > >
> > > Pingfan reported that the following causes a fault:
> > >
> > >   echo "filename ~ \"cpu\"" > events/syscalls/sys_enter_openat/filter
> > >   echo 1 > events/syscalls/sys_enter_at/enable
> > >
> > > The reason is that trace event filter treats the user space pointer
> > > defined by "filename" as a normal pointer to compare against the "cpu"
> > > string. If the string is not loaded into memory yet, it will trigger a
> > > fault in kernel space:
> >
> > If a userspace pointer can end up the kernel structure then presumably
> > a 'dodgy' user program can supply an arbitrary kernel address instead?
> > This may give the user the ability to read arbitrary kernel addresses
> > (including ones that are mapped to PCIe IO addresses).
> > Doesn't sound good at all.
> 
> 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.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)