commit 1990f30743c7c98b039fdf32d2581e1d9737d75e Author: Willy Tarreau Date: Sun Sep 23 11:47:44 2007 +0200 Linux 2.6.20.20 commit 652a44b1e452415b75713224b6df4d26a7b4e5a0 Author: Tom Alsberg Date: Tue May 8 07:30:31 2007 -0700 CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix As discovered here today, the change in Kernel 2.6.17 intended to inhibit users from setting RLIMIT_CPU to 0 (as that is equivalent to unlimited) by "cheating" and setting it to 1 in such a case, does not make a difference, as the check is done in the wrong place (too late), and only applies to the profiling code. On all systems I checked running kernels above 2.6.17, no matter what the hard and soft CPU time limits were before, a user could escape them by issuing in the shell (sh/bash/zsh) "ulimit -t 0", and then the user's process was not ever killed. Attached is a trivial patch to fix that. Simply moving the check to a slightly earlier location (specifically, before the line that actually assigns the limit - *old_rlim = new_rlim), does the trick. Do note that at least the zsh (but not ash, dash, or bash) shell has the problem of "caching" the limits set by the ulimit command, so when running zsh the fix will not immediately be evident - after entering "ulimit -t 0", "ulimit -a" will show "-t: cpu time (seconds) 0", even though the actual limit as returned by getrlimit(...) will be 1. It can be verified by opening a subshell (which will not have the values of the parent shell in cache) and checking in it, or just by running a CPU intensive command like "echo '65536^1048576' | bc" and verifying that it dumps core after one second. Regardless of whether that is a misfeature in the shell, perhaps it would be better to return -EINVAL from setrlimit in such a case instead of cheating and setting to 1, as that does not really reflect the actual state of the process anymore. I do not however know what the ground for that decision was in the original 2.6.17 change, and whether there would be any "backward" compatibility issues, so I preferred not to touch that right now. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds commit 0d4a39318e6177ed424e92fe9ea75b514e782cdc Author: Andi Kleen Date: Fri Sep 21 16:16:18 2007 +0200 [PATCH] x86_64: Zero extend all registers after ptrace in 32bit entry path. Strictly it's only needed for eax. It actually does a little more than strictly needed -- the other registers are already zero extended. Also remove the now unnecessary and non functional compat task check in ptrace. This is CVE-2007-4573 Found by Wojciech Purczynski Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright