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

[Steven Rostedt]

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 ;-)

> 
> ...
> > +	if (likely((unsigned long)str >= TASK_SIZE)) {
> > +		/* For safety, do not trust the string pointer */
> > +		if (!strncpy_from_kernel_nofault(kstr, str, USTRING_BUF_SIZE))
> > +			return NULL;
> > +	} else {
> > +		/* user space address? */
> > +		ustr = (char __user *)str;
> > +		if (!strncpy_from_user_nofault(kstr, ustr, USTRING_BUF_SIZE))
> > +			return NULL;  
> 
> Is that check against TASK_SIZE even correct for all architectures?
> copy_to/from_user() uses access_ok() - which is architecture dependant.

The problem with access_ok() (which I tried first) is that it can't be used
from interrupt context, and this check can happen in interrupt context.
Either way, if we pick the wrong one for the arch, the only thing bad that
can happen is that it returns "fault" and the filter fails, just like if
the pointer was to bad memory.

> 
> I think you need to remember where the pointer came from.
> 

Why?

-- Steve