Bug 437114 (CVE-2008-1294)

Summary: CVE-2008-1294 kernel: setrlimit(RLIMIT_CPUINFO) with zero value doesn't inherit properly across children
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: anton, dhoward, kreilly, mjc, nhorman, skakar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-23 16:41:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 437121, 437122    
Bug Blocks:    

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)