linux-kernel - Re: BUG: bad usercopy in memdup

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:   Tue, 19 Dec 2017 13:36:46 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     "Tobin C. Harding" <me@...in.cc>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux-MM <linux-mm@...ck.org>,
        syzbot 
        <bot+719398b443fd30155f92f2a888e749026c62b427@...kaller.appspotmail.com>,
        David Windsor <dave@...lcore.net>, keun-o.park@...kmatter.ae,
        Laura Abbott <labbott@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ingo Molnar <mingo@...nel.org>,
        syzkaller-bugs@...glegroups.com, Will Deacon <will.deacon@....com>
Subject: Re: BUG: bad usercopy in memdup_user

On Tue, Dec 19, 2017 at 5:22 AM, Matthew Wilcox <willy@...radead.org> wrote:
>
> Could we have a way to know that the printed address is hashed and not just
> a pointer getting completely scrogged?  Perhaps prefix it with ... a hash!
> So this line would look like:

The problem with that is that it will break tools that parse things.

So no, it won't work.

When we find something like this, we should either remove it, fix the
permissions, or switch to %px.

In this case, there's obviously no permission issue: it's an error
report. So it's either "remove it, or switch to %px".

I'm personally not clear on whether the pointer really makes any sense
at all. But if it does, it should just be changed to %px, since it's a
bug report.

But honestly, what do people expect that the pointer value will
actually tell you if it is unhashed?

I suspect that an "offset and size within the kernel object" value
might make sense.  But what does the _pointer_ tell you?

I've noticed this with pretty much every report. People get upset
about the hashing, but don't seem to actually be able to ever tell
what the f*ck they would use the non-hashed pointer value for.

I've asked for this before: whenever somebody complains about the
hashing, you had better tell exactly what the unhashed value would
have given you, and how it would have helped debug the problem.

Because if you can't tell that, then dammit, then we should just
_remove_ the stupid %p.

Instead, people ask for "can I get everything unhashed" even when they
can't give a reason for it.

            Linus