+++ This bug was initially created as a clone of Bug #628498 +++ Description of problem: Reported by Solar Designer. This issue was fixed during the 2.0/2.3 kernel days: http://marc.info/?l=bugtraq&m=93728282528791 "(2.0.38) (2.2.12) (*) While investigating the problem mentioned above, as well as porting Pavel Kankovsky's fd 0-2 fix to Linux 2.2, I've noticed yet another problem with execve(2), which has a similar impact. The problem is that all arguments are first counted, and their lengths measured, and only after that the results are checked against the limit (32 pages, or 128 KB on x86). Thus, it is possible to make execve(2) spend a significant amount of CPU cycles in the kernel, with the big kernel lock obtained. In terms of real time, I was able to get 25 minutes for one execve(2) call on Alpha (the 64-bit address space helps), and several seconds on modern x86 boxes. The latter can still be halted to death by repeating the call in a loop, and in a few processes. Fixing this required a trivial modification to the argument counting function, and a switch to strnlen_user() for the strings (on 2.2). The latter is an architecture-specific assembly function. My patch only fixes it on x86 and Alpha, and 2.2.13 will do that for some more architectures (but maybe not all supported by Linux 2.2, yet). Linux 2.0 didn't have a strlen_user(), and thus used a simple loop in this place, which had the same vulnerability (but not in my 2.0.38 patch, of course). Note that RLIMIT_AS can be used as a workaround for this problem, and you should probably be using it for other reasons, anyway." But it was reported to be reintroduced: http://seclists.org/oss-sec/2010/q3/247 "Now it appears that, besides the issue that started this thread, the same problem I mentioned above got re-introduced. We still have strnlen_user() and the "max" argument to count(), but we no longer have hard limits for "max". Someone set MAX_ARG_STRINGS to 0x7FFFFFFF, and this is just too much. MAX_ARG_STRLEN is set to 32 pages, and these two combined allow a userspace program to make the kernel loop for days. So I think that we should re-introduce some artificial limit(s), maybe adjustable by root (by the host system's real root only when container virtualization is involved). Maybe we should lower MAX_ARG_STRINGS and/or maybe we should limit the portion of stack space usable for argv to, say, 0.75 GB (or even less)." He suggested: - if (size > rlim[RLIMIT_STACK].rlim_cur / 4) { + if (size > rlim[RLIMIT_STACK].rlim_cur / 4 || + size > MAX_ARG_STACK) { -#define MAX_ARG_STRINGS 0x7FFFFFFF +#define MAX_ARG_STACK (0xC0000000UL / 4) +#define MAX_ARG_STRINGS (MAX_ARG_STACK / 5) but may not be a sufficient solution. --- Additional comment from eteo on 2010-09-01 00:40:11 EDT --- Roland proposed, http://lkml.org/lkml/2010/8/30/138. I don't think this justify a CVE name, and should be handled as a normal bug.
[PATCH 2/3] execve: improve interactivity with large arguments http://lkml.org/lkml/2010/9/7/495 [PATCH 3/3] execve: make responsive to SIGKILL with large arguments http://lkml.org/lkml/2010/9/7/497
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-227.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html