from a *brief* look at the bugs (i.e., i may very well be wrong): there're 3 overflow bugs, so i'll comment on them only.mikeeusa wrote:http://www.debian.org/security/2004/dsa-479
2.4.25 is affected.
Does grsecurity make it unaffected?
I don't like having to recompile EVERY 1.5 months, this is shit linux is shit ass security wise.
Please let grsecurity make it not vulnerable. This is such shit shit shit.
Is it vuln?
the R128 bug is an integer overflow in calculating the size of a kmalloc()'ed buffer. however the same calculation is used later when copying from userland into that buffer, so there's no buffer overflow in there, not sure why this was labeled as such a bug. the only bad thing that can happen is an out-of-bounds read later in the code when the ring buffer is filled in, it could either oops the kernel or feed garbage to the ring buffer, i don't see how that would be exploitable. note also that to trigger these integer overflows at all you will have to be able to issue ioctl()'s and at least on my system the device entries are accessible to root only.
the second bug is in ncpfs which was fixed in 2.4.25 already (i mean, in vanilla).
the third bug is in isofs and it's a (true) overflow into a kmalloc()'d page, what you can do with it is not clear, someone will have to look into the kmalloc() allocator and see how it can be abused.
as for what protection grsecurity/PaX gives you: if you're running with KERNEXEC/RANDKSTACK enabled then you can at least be sure that there's no direct way to execute exploit code directly in ring-0 (the kernel's privilege level on i386), the exploit must perform a return-to-libc style attack - how you do that without even having as much as a stack overflow is not clear to me.