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 12:24:36 -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 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 ;-)

> 
> ...
> > +	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