You just convinced me that you've never *really* thought about it the way
a security professional would.
The key point you overlooked is that if it's only triggered under an abnormal
workload, the attacker can usually *arrange* said workload. Need at least
10K processes for something to trigger, and there's usually only 400 on the
box? No problem, just fork-bomb yourself 9,600 processes and then run the
exploit. You can only avoid the reboot for a bugfix if you can *prove*
that the setup condition(s) cannot possibly happen on the system unless
the security has already been breached (for example, "we don't need to
reboot to fix this because there is a system-wide process limit of 1,250
per user, there are only 7 userids on the system, and you need to already
be root to reset the limit").
If I wrote up a 'DoS Advisory' for every time I manage to find another way
to oops or panic a -mm kernel, I'd probably have a a very large pile of
advisories. However, the fact that I managed to oops or panic their software
has almost always been incentive enough for the maintainers to fix it, there's
It should however be noted that a number of people who take security seriously
think the paxteam is totally out to lunch with some of their ideas. The last
time I looked at their "security patch" (admittedly, that was back around
2.6.17 or so), a large chunk of it was pretty much cargo-cult security that
addressed specific gotcha's that have in the past been used (like symlink races
in /tmp), rather than address the *actual* security issue (for instance,
"compilers shouldn't overwrite system config files") in a comprehensive manner.
A big chunk of the rest was their version of execshield, which required
cutting the available address space in half (a big issue for 32-bit archs).
The telling point is that they didn't see this as being possibly a problem for
You've apparently overlooked the fact that although there are probably still
a lot of security bugs in the kernel, an attacker is ...
