Re: [PATCH] x86/refcount: Implement fast refcount_t handling

From	"PaX Team" <pageexec@freemail.hu>
Newsgroups	linux.kernel
Subject	Re: [PATCH] x86/refcount: Implement fast refcount_t handling
Date	2017-04-26 04:20 +0200
Message-ID	<tAkIF-4uM-1@gated-at.bofh.it> (permalink)
References	<tzK2u-6io-9@gated-at.bofh.it> <tAkIF-4uM-3@gated-at.bofh.it> <tAbP3-7aO-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 25 Apr 2017 at 9:39, Kees Cook wrote:

> On Tue, Apr 25, 2017 at 4:26 AM, PaX Team <pageexec@freemail.hu> wrote:
> > INT_MAX threads would be needed when the leaking path is locked so
> > that it can only be exercised once and you'll need to get normal
> > (balanced) paths preempted just after the increment. if the leaking
> > path is lockless (can be exercised in parallel without bounds) then
> > 2 threads are enough where the one triggering the signed overflow
> > would have to be preempted while the other one does INT_MAX increments
> > and trigger the UAF. this is where the other mechanisms i talked about
> > in the past become relevant: preemption or interrupts can be disabled
> > or negative refcount values can be detected and acted upon (your blind
> > copy-pasting effort passed upon this latter opportunity by not
> > specializing the 'jo' into 'js' for the refcount case).
> 
> Well, it's not "blind" -- I'm trying to bring the code as-is to
> upstream for discussion/examination with as little functional
> differences as possible so it's easier to compare apples to apples.

you copied code from a version which is at least 2 major kernel revisions
behind (so much for those apples), you chose the one version which had a
bug that you didn't spot nor fix properly, you didn't realize the opportunity
that a special refcount type represents, you claimed refcount underflows
aren't exploitable but copied code that would detect signed underflow, you
didn't understand the limits and edge cases i explained above... need i go
on? doesn't leave one with great confidence in your ability to understand
and maintain this code...

Thread

Re: [PATCH] x86/refcount: Implement fast refcount_t handling "PaX Team" <pageexec@freemail.hu> - 2017-04-25 13:30 +0200
  Re: [PATCH] x86/refcount: Implement fast refcount_t handling Kees Cook <keescook@chromium.org> - 2017-04-25 18:50 +0200
    Re: [PATCH] x86/refcount: Implement fast refcount_t handling "PaX Team" <pageexec@freemail.hu> - 2017-04-26 04:20 +0200
      Re: [PATCH] x86/refcount: Implement fast refcount_t handling Kees Cook <keescook@chromium.org> - 2017-04-26 06:50 +0200

csiph-web