[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170424220128.j7nnhuohqdqbiki7@hirez.programming.kicks-ass.net>
Date: Tue, 25 Apr 2017 00:01:28 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: PaX Team <pageexec@...email.hu>, LKML <linux-kernel@...r.kernel.org>,
Eric Biggers <ebiggers3@...il.com>,
Christoph Hellwig <hch@...radead.org>,
"axboe@...nel.dk" <axboe@...nel.dk>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Elena Reshetova <elena.reshetova@...el.com>,
Hans Liljestrand <ishkamiel@...il.com>,
David Windsor <dwindsor@...il.com>,
"x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jann Horn <jann@...jh.net>, "David S. Miller" <davem@...emloft.net>,
linux-arch <linux-arch@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling
On Mon, Apr 24, 2017 at 01:40:56PM -0700, Kees Cook wrote:
> I think we're way off in the weeds here. The "cannot inc from 0" check
> is about general sanity checks on refcounts.
I disagree, although sanity check are good too.
> It should never happen, and if it does, there's a bug.
The very same is true of the overflow thing.
> However, what the refcount hardening protection is trying to do is
> protect again the exploitable condition: overflow.
Sure..
> Inc-from-0 isn't an exploitable condition since in theory
> the memory suddenly becomes correctly managed again.
It does not. It just got free'ed. Nothing will stop the free from
happening (or already having happened).
> We're just discussing different things.
No, both are bugs, neither overflow not inc-from-zero _should_ happen.
The whole point is that code is buggy. If it weren't for that, we'd not
be doing this.
How is the below not useful fodder for an exploit? It might be a less
common bug, and perhaps a bit more fiddly to make work, but afaict its
still a full use-after-free and therefore useful.
---
Thread-A Thread-B
if(dec_and_test(&obj->ref)) { // true, ref==0
inc(&obj->ref) // ref: 0->1
kfree(obj);
}
~~~/ Thread-C /~~~
obj = kmalloc(); // is obj from Thread-A
obj->ref = 1;
obj->func = ....
obj->func();
-- OR --
put(obj);
if (dec_and_test(&obj->ref))
kfree(obj); // which was of Thread-C
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
