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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | anton, dhoward, kreilly, mjc, nhorman, skakar |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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: | |
Embargoed: | |||
Bug Depends On: | 437121, 437122 | ||
Bug Blocks: |
Description
Jan Lieskovsky
2008-03-12 14:36:56 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
symptom.
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. Cheers, -- Tom Proposed upstream patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9926e4c74300c4b31dee007298c6475d33369df0 Link with more detailed information: http://marc.info/?l=oss-security&m=120527771109026&w=4 This was addressed via: Red Hat Enterprise Linux version 5 (RHSA-2008:0612) |