I know. I want to know if someone with a kernel >=2.6.39 and applied grsecurity patch can successfully use this exploit or if grsecurity protects from this exploit.

Just tried it on 3.0.4 with grsecurity enabled, and it didn't work, so there.

Thanks. I guess It's finally time for me to move every machine to a grsecurity kernel.

Would you be interested in a grsecurity distro?

I'd love to see up to date stable grsecurity kernel repositories for the major distributions (ubuntu, debian, rhel/centos) that provide patched versions of the distribution kernel. You can configure most of grsecurity via the sysctl interface. At the moment it is always a bit of hassle to patch & compile a kernel from hand even with the great debian/ubuntu kernel-package.

I don't think I'll use an extra distribution. But something like a hardened LAMP/LAPP stack for shared hosting out of the box in a distribution would be great (I think in terms of easy chrooting of users and php, secure permissions, etc.pp) However, I guess everyone has different needs and there is no one size that fits for all.

Why is grsecurity not merged upstream?

I don't know. I'm just on the end-user side. Just a guess from my (pretty limited) understanding of the issue: The grsecurity[1] patch includes PaX[2] that can break a lot of software. e.g. Java and X11 and there are sometimes other unwanted side effects as well. And I've found a blog post stating that the author does not want to maintain a upstream patch[3].

1: http://en.wikipedia.org/wiki/Grsecurity

2: http://en.wikipedia.org/wiki/PaX

3: http://www.corsac.net/?rub=blog&post=1535

Egos and the childish behaviour of half the kernel developers involved in Linux, this includes Spender and co at grsec