Bug 437114 (CVE-2008-1294) - CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inherit properly across children
Summary: CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inher...
Alias: CVE-2008-1294
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 437121 437122
TreeView+ depends on / blocked
Reported: 2008-03-12 14:36 UTC by Jan Lieskovsky
Modified: 2021-11-12 19:48 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-23 16:41:07 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0612 0 normal SHIPPED_LIVE Important: kernel security and bug fix update 2008-08-06 14:46:27 UTC

Description Jan Lieskovsky 2008-03-12 14:36:56 UTC
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,

David Peer.


Comment 1 Jan Lieskovsky 2008-03-12 14:38:44 UTC
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

Comment 2 Jan Lieskovsky 2008-03-12 14:39:17 UTC
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
yet cached.

I expect my patch to be in the next Linux 2.6.21 release candidate.

  -- Tom

Comment 6 Jan Lieskovsky 2008-03-12 16:15:48 UTC
Link with more detailed information:


Comment 7 Vincent Danen 2010-12-23 16:41:07 UTC
This was addressed via:

Red Hat Enterprise Linux version 5 (RHSA-2008:0612)

Note You need to log in before you can comment on or make changes to this bug.