Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Apr 2017 09:39:52 -0700
From: Kees Cook <>
To: PaX Team <>
Cc: Peter Zijlstra <>, LKML <>, 
	Eric Biggers <>, Christoph Hellwig <>, 
	"" <>, James Bottomley <>, 
	Elena Reshetova <>, Hans Liljestrand <>, 
	David Windsor <>, "" <>, Ingo Molnar <>, 
	Arnd Bergmann <>, Greg Kroah-Hartman <>, Jann Horn <>, 
	"David S. Miller" <>, linux-arch <>, 
	"" <>
Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 4:26 AM, PaX Team <> 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.
(Which already resulted in more eyes looking at the code to find a bug
-- thanks Jann!) But yes, jo -> js hugely increases the coverage. I'll
make that change for v2.



Kees Cook
Pixel Security

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.