Red Hat Bugzilla – Bug 437114
CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inherit properly across children
Last modified: 2010-12-23 11:41:07 EST
Description of problem:
David Peer has reported the following problem in the kernel handling
of "ulimit" function:
I'm using zsh 4.3.2-25 on debian, and noticed that when any user
run: ulimit -t 0 from its shell, he manages to disable the cputime
limitation if any. for example:
I have a debian system that has cpu time limitation of 1 minute soft,
and 2 minutes hard. If the user run: ulimit -t 0, he can run jobs without
any cputime limitation: You can see the output from "top" command, that it ran
the job "testload" for more then 6 minutes.
Thanks in advanced,
Comment to Micah Cowan to this issue:
David Peer wrote:
> > If the user run: ulimit -t 0, he can run jobs without any cputime
> > limitation:
This sounds more like a kernel problem to me than a zsh bug. I get the
same behavior on my Ubuntu 7.04 (beta) system, in _bash_.
I note that getrlimit(2) says:
In 2.6.x kernels before 2.6.17, a RLIMIT_CPU limit of 0 is wrongly
treated as "no limit" (like RLIM_INFINITY). Since kernel 2.6.17, set‐
ting a limit of 0 does have an effect, but is actually treated as a
limit of 1 second.
However, I'm running 2.6.20(-14-generic), and still experiencing that
Another Tom reaction:
I checked the problem earlier today (by reference of David who pointed
it out to me - thanks, David). The problem is apparently in the Linux
kernel, where the check for trying to set RLIMIT_CPU = 0 is done a bit
too late, and has nothing to do with zsh. Specifically, the same
symptoms were visible with other shells (ash, bash) too.
I checked the Linux kernel sources and found the solution in
kernel/sys.c. Attached is a copy of my message with the patch to the
Linux-Kernel Mailing List.
One issue that may be relevant within zsh, though, is that it appears
that zsh caches the limits set, and since that check in Linux "cheats"
by setting the value to 1 when 0 is requested, entering "ulimit -a"
does not call getrlimit(...) at all and does show 0 after issuing the
command "ulimit -t 0", although getrlimit(RLIMIT_CPU, ...) would
return 1. The correct limit is seen in a subshell where this is not
I expect my patch to be in the next Linux 2.6.21 release candidate.
Proposed upstream patch:
Link with more detailed information:
This was addressed via:
Red Hat Enterprise Linux version 5 (RHSA-2008:0612)