|
Message-ID: <CAG48ez0udSMcD2GhgVj4amsqwVJ8qEw31A8SDnDjzgjMjAsHbg@mail.gmail.com> Date: Wed, 26 Apr 2017 02:25:23 +0200 From: Jann Horn <jannh@...gle.com> To: Kees Cook <keescook@...omium.org> Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, PaX Team <pageexec@...email.hu>, 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>, "David S. Miller" <davem@...emloft.net>, Rik van Riel <riel@...hat.com>, linux-arch <linux-arch@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection On Wed, Apr 26, 2017 at 12:56 AM, Kees Cook <keescook@...omium.org> wrote: > This protection is a modified version of the x86 PAX_REFCOUNT > implementation from PaX/grsecurity. This speeds up the refcount_t API by > duplicating the existing atomic_t implementation with a single instruction > added to detect if the refcount has wrapped past INT_MAX (or below 0) > resulting in a signed value. [...] > +static __always_inline void refcount_dec(refcount_t *r) > +{ > + asm volatile(LOCK_PREFIX "decl %0\n\t" > + REFCOUNT_CHECK_UNDERFLOW(4) > + : [counter] "+m" (r->refs.counter) > + : : "cc", "cx"); > +} What purpose do checks on decrement now have? The mitigation is only intended to deal with (positive) overflows, right? AFAICS if you hit this code, similar to the inc-from-0 case, you're already in a UAF situation?
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.