[grsec] PAX_REFCOUNT doesn't work

[pageexec at freemail.hu]

On 2 Sep 2008 at 11:33, Carlos Carvalho wrote:

> I used 2.6.26.3-200808241848, which was the latest one. There was an
> update only yesterday.

how about grsecurity-2.1.12-2.6.26.3-200808262105.patch ? ;)

> I didn't understand this part of the explanation:
> 
> 	  The tradeoff is that data structures protected by an oveflowed
> 	  refcount will never be freed and therefore will leak memory.  Note
> 	  that this leak also happens even without this protection but in
> 	  that case the overflow can eventually trigger the freeing of the
> 	  data structure while it is still being used elsewhere, resulting
> 	  in the exploitable situation that this feature prevents.
> 
> You mean that the kernel always leaks memory but it frees the
> structure when it overflows, thus plugging the leak?

yes, as long as the refcount doesn't reach 0, the kernel considers the
given object as in-use and doesn't free the associated memory.

so in normal (non-attack) circumstances when the refcount leak does
not actually result in a wrap, the object is effectively leaked memory.
under attack however the refcount can be made to wrap and that's when
the real trouble begins.

> You say that this plugging is a problem because the freeing may happen
> when the structure is still in use, therefore you chose to never free
> it? Instead you prefer to make the memory leak permanent? 

in terms of effects, yes, that's the result, but the implementation does
not actually care about the act of freeing, it cares about detecting the
tell-tale sign of a refcount overflow at which point it prevents further
refcount increments (or decrements, as the case may be). so just like with 
other PaX features, the underlying kernel bug (unbalanced refcount operations)
is not fixed per se, only its exploitation is detected and prevented (at
least that's the hope ;).