linux-kernel - Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault

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, 25 Feb 2019 15:52:40 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        stable <stable@...r.kernel.org>,
        Changbin Du <changbin.du@...il.com>,
        Jann Horn <jannh@...gle.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access
 kernel memory that can fault

On Mon, Feb 25, 2019 at 09:33:09AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 24, 2019 at 09:26:45AM -0800, Linus Torvalds wrote:
> > PeterZ, do you remember the particular use case that triggered that
> > commit 7c4788950ba5 ("x86/uaccess, sched/preempt: Verify access_ok()
> > context")?
> 
> This one, if I'm not mistaken.
> 
> ---
> 
> commit ae31fe51a3cceaa0cabdb3058f69669ecb47f12e
> Author: Johannes Weiner <hannes@...xchg.org>
> Date:   Tue Nov 22 10:57:42 2016 +0100
> 
>     perf/x86: Restore TASK_SIZE check on frame pointer
>     
>     The following commit:
>     
>       75925e1ad7f5 ("perf/x86: Optimize stack walk user accesses")
>     
>     ... switched from copy_from_user_nmi() to __copy_from_user_nmi() with a manual
>     access_ok() check.
>     
>     Unfortunately, copy_from_user_nmi() does an explicit check against TASK_SIZE,
>     whereas the access_ok() uses whatever the current address limit of the task is.
>     
>     We are getting NMIs when __probe_kernel_read() has switched to KERNEL_DS, and
>     then see vmalloc faults when we access what looks like pointers into vmalloc
>     space:

Also note that this was before we did:

commit 88b0193d9418c00340e45e0a913a0813bc6c8c96
Author: Will Deacon <will.deacon@....com>
Date:   Tue May 9 18:00:04 2017 +0100

    perf/callchain: Force USER_DS when invoking perf_callchain_user()
    
    Perf can generate and record a user callchain in response to a synchronous
    request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS),
    then we can end up walking the user stack (and dereferencing/saving whatever we
    find there) without the protections usually afforded by checks such as
    access_ok.
    
    Rather than play whack-a-mole with each architecture's stack unwinding
    implementation, fix the root of the problem by ensuring that we force USER_DS
    when invoking perf_callchain_user from the perf core.
    
    Reported-by: Al Viro <viro@...IV.linux.org.uk>
    Signed-off-by: Will Deacon <will.deacon@....com>
    Acked-by: Peter Zijlstra <peterz@...radead.org>
    Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
    Cc: Jiri Olsa <jolsa@...hat.com>
    Cc: Linus Torvalds <torvalds@...ux-foundation.org>
    Cc: Thomas Gleixner <tglx@...utronix.de>
    Signed-off-by: Ingo Molnar <mingo@...nel.org>

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c04917cad1bf..1b2be63c8528 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -229,12 +229,18 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 		}
 
 		if (regs) {
+			mm_segment_t fs;
+
 			if (crosstask)
 				goto exit_put;
 
 			if (add_mark)
 				perf_callchain_store_context(&ctx, PERF_CONTEXT_USER);
+
+			fs = get_fs();
+			set_fs(USER_DS);
 			perf_callchain_user(&ctx, regs);
+			set_fs(fs);
 		}
 	}