linux-kernel - Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 14 Sep 2017 15:53:41 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Helge Deller <deller@....de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
 usages

On (09/08/17 10:25), Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> > if the addr is not in kernel .text, then try dereferencing it and check
> > if the dereferenced addr is in kernel .text.
> 
> If it really is a function pointer, then we know that it is safe
> to dereference. But if it isn't, then maybe not?

yes. I thought about it - we can do %pS on a pointer to a global
structure. so that simple heuristic would not work reliably. we
parse ELF sections, and we know the address range of .opd section,
so we can check if the supplied pointer is within the .opd section
or not.

.opd does exist on ia64. not sure what's the name of ELF descriptor
section on ppc64/parisc64.

if we will be able to simply do

	.opd->address  <=  ptr  <=  .opd->address + .opd->size

then it mostly should work for us. I guess.

> If it is a function pointer then dereferening will indeed give
> us a .text address. But if it isn't, it might still give us a
> .text address (we could reduce the probability of a false hit
> by checking that the .text address was exactly on a symbol with
> no offset ... but data values that happen to be the addresses of
> function entry points are possible).

hm. yes, need to think more.

	-ss