"And obviously this flaw doesn't affect people that don't use any security modules."
Wow, you couldn't be more wrong. The flaw is in the network tunnelling code. Nothing was wrong with the LSMs, spender was just able to get around SELinux protections (by running his code in a domain that wasn't being confined by SELinux, wow, impressive.) Running his exploit in a confined SELinux domain would have prevented any damages. Any other LSM (SMACK/TOMOYO/AppArmour) doesn't even to try to protect against this class of kernel bugs.
"The kernel's not likely to have a "fixed" re-release for this version"
Again, you couldn't be more ignorant. Greg kh has stable releases. He has stable releases for 2.6.30. Magic. A 'fixed' re-release.
To fix some other incorrect statement in these comments. Linux allowed the mapping of page 0. It always has, mainly for msdos compatability. WINE makes use of mapping the zero page, as does the vm86 emulation used by DOSEMU, and a number of programmers have made use of mapping the NULL page as expected behaviour in their programs. I call it bad style, but it works.
When I wrote the Linux kernel patches to prevent the mapping of the NULL page and we specifically wrote it to allow certain programs to do this. As we find and fix those programs we are tightening the restrictions. See how in the 2.6.31 code (long before the exploit was known) we moved the mmap NULL page protections out of the LSM and into the generic security subsystem, thus they could help people who build without any LSM.
The linux kernel (in response to this exploit) has decided to start building with -fno-delete-null-pointer-checks. There is a performance trade off, but it does harden the kernel again future bugs like this one. Normally this would have been a NULL pointer OOPS (and that's how the vulnerability was found and fixed before spender wrote his exploit) when it should have been a fine situation with a safe return code. (I think the argument that the gcc optimization is generally a bug have been sufficiently debunked, it's busted tunneling code, no ifs ands or buts)
I'm working with the gcc team to come up with a way to find these situations but as many have pointed out, considering inline functions and macros it's not uncommon to know that a given branch is impossible to take. Maybe we can use this work to make it faster to find these bugs in the future, but generally, optimizing out branches that are known to be impossible to take is the right thing to do.....