linux-kernel - Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

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:   Thu, 8 Mar 2018 09:26:11 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        "Tobin C . Harding" <me@...in.cc>, Joe Perches <joe@...ches.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.cz>
Subject: Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

On Thu, Mar 8, 2018 at 8:45 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Umm. Look again. It _does_ affect plain %p.
>
> You're correct that it doesn't affect %px and %pK, since those never
> printed out (null) in the first place.
>
> It not only affects %p, but it also affects %pS and friends (sSfFB),

Looking around at the x86 panic thing, %p doesn't matter that much,
but %p[sSfFB] really do.

We use %pS/%pB to print out the instruction pointer. And a fault might
be due to the instruction pointer being bad.

And then we very much need to see the value, which the current
%pS-and-friends falls back to.

So printing <efault> would actually be horrible, in addition to the
extra page fault being wrong. In fact, _only_ NULL itself needs to be
printed as (null), because we'd care if it's 0 or 8 or something.

The other ones? The ones that would actually fault (%pI and friends)
would not matter.

The hex dumping one _might_ actually be useful if it got a buffer with
'probe_kernel_read()' and stopped half-way on problems.   Maybe. The
others I can't imagine really care. efault or hex address.

             Linus