Bug 437114 - (CVE-2008-1294) CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inherit properly across children
CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inher...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 437121 437122
  Show dependency treegraph
Reported: 2008-03-12 10:36 EDT by Jan Lieskovsky
Modified: 2010-12-23 11:41 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-23 11:41:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2008-03-12 10:36:56 EDT
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 10:38:44 EDT
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 10:39:17 EDT
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 12:15:48 EDT
Link with more detailed information:

Comment 7 Vincent Danen 2010-12-23 11:41:07 EST
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.