linux-kernel - Re: [PATCH 0/2] [GIT PULL] tracing: Two more fixes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Feb 2019 09:08:38 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/2] [GIT PULL] tracing: Two more fixes

On Fri, Feb 15, 2019 at 6:21 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
>  - Have kprobes not use copy_from_user to access kernel addresses
>    as this is now considered a security issue.

No, you people are confused.

The problem isn't that it's using a user access function on kernel memory.

The problem is that it's using a user access function on a complete
garbage pointer that happens to not even be a valid pointer at all.

You get a GP fault because the code tries to access an address at
0x2e646c2f6374652f.

That's not a valid pointer on x86-64. Nothing to do with user or
kernel, everything to do with "it's garbage".

Switching over to probe_mem_read() just means that even non-canonical
address faults are ignored. But it has absolutely nothing to do with
"kernel addresses" or any security issues.

So the patch looks like it might be ok, but the explanations for it
are garbage and only confuse the issue.

Please fix the explanations, I don't want to have actively wrong
commit messages for when people start looking at things like this.

                   Linus