Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948214AbdDYQgi (ORCPT ); Tue, 25 Apr 2017 12:36:38 -0400 Received: from mail-it0-f50.google.com ([209.85.214.50]:38050 "EHLO mail-it0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1431836AbdDYQgT (ORCPT ); Tue, 25 Apr 2017 12:36:19 -0400 MIME-Version: 1.0 In-Reply-To: <58FF3273.2718.1C99E5A3@pageexec.freemail.hu> References: <20170421220939.GA65363@beast> <20170424220128.j7nnhuohqdqbiki7@hirez.programming.kicks-ass.net> <58FF3273.2718.1C99E5A3@pageexec.freemail.hu> From: Kees Cook Date: Tue, 25 Apr 2017 09:36:17 -0700 X-Google-Sender-Auth: wpueIJhJn48g9p4pHKKlHHLIKig Message-ID: Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling To: PaX Team Cc: Peter Zijlstra , LKML , Eric Biggers , Christoph Hellwig , "axboe@kernel.dk" , James Bottomley , Elena Reshetova , Hans Liljestrand , David Windsor , "x86@kernel.org" , Ingo Molnar , Arnd Bergmann , Greg Kroah-Hartman , Jann Horn , "David S. Miller" , linux-arch , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1506 Lines: 37 On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > On 25 Apr 2017 at 0:01, Peter Zijlstra wrote: >> 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); >> } > > ... and tell me why an attacker would let Thread-B do that increment > (that you're trying to detect) *before* the underlying memory gets > reused and thus the 0 changed to something else? hint: he'll do everything > in his power to prevent that, either by winning the race or if there's > no race (no refcount users outside his control), he'll win every time. > IOW, checking for 0 is pointless and you kinda proved it yourself now. Right, having a deterministic protection (checking for overflow) is best since it stops all exploits using that path. Hoping that an attacker is unlucky and hits a notification after they've already landed their corruption is not a very useful defense. It certainly has a non-zero value, but stopping overflow 100% is better. Especially when we can do it with no meaningful change in performance which lets us actually do the atomic_t -> refcount_t conversion everywhere. -Kees -- Kees Cook Pixel Security