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

[Petr Mladek]

On Thu 2018-03-08 09:26:11, Linus Torvalds wrote:
> On Thu, Mar 8, 2018 at 8:45 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.

This all makes perfect sense. And I actually intended to do it this
way. Unfortunately, I sent the first RFC too fast without updating
the check for %p* specifiers. I am sorry for the confusion.


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

I will try to keep it simple and check only the 1st byte for now.
It should prevent most of the possible silent crashes.

Here is the 2nd attempt. It never calls probe_kernel_read() when
the data need not be accessed: