RE: [PATCH v2] tracing: Add test for user space strings when filtering on string pointers

[David Laight]

From: Steven Rostedt
> Sent: 10 January 2022 17:25
> 
> On Mon, 10 Jan 2022 17:11:52 +0000
> David Laight <David.Laight@xxxxxxxxxx> wrote:
> 
> > From: Steven Rostedt
> > > Sent: 10 January 2022 16:56
> > >
> > > From: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > >
> > > 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)