[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170907075653.GA533@jagdpanzerIV.localdomain>
Date: Thu, 7 Sep 2017 16:56:53 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Helge Deller <deller@....de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
usages
Hello Helge,
On (09/07/17 08:01), Helge Deller wrote:
[..]
> > hm...
> > can we fix it in lib/vsprintf.c instead?
thanks for a quick reply.
> There is nothing to fix in vsprintf, because it is already providing
> both %pF and %pS for the two different architecture-specific API call
> implementations.
[..]
> ia64, ppc64 and parisc64 architectures will be wrong and may lead
> to kernel crashes in the worst case.
^^^^^^^^^^^^^^^^^
I was thinking about this part.
sorry, I don't have access to ia64/ppc64/parisc64 so can't check it or
test it. here is a question, does function descriptor belong to a special
section? can we check that supplied ptr belongs to a descriptor section
and avoid dereference_function_descriptor() if it doesn't? (just fall
through directly to symbol_string() in this case). is this possible?
I mean, there is no mechanism to prevent this type of wrongdoings in
the future, we can't scan the entire kernel for wrong pF/pS all the
time.
BTW, are we sure we can crash? when attempt to deference IP from
the given descriptor? shall we handle page fault in this case and
do something sane? just asking.
-ss
Powered by blists - more mailing lists