RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 629178 - kernel: Problem with execve(2) reintroduced [rhel-6.1]
Summary: kernel: Problem with execve(2) reintroduced [rhel-6.1]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Dave Anderson
QA Contact: Caspar Zhang
URL:
Whiteboard:
Depends On: 628498 629179 629180
Blocks: 629176 661731
TreeView+ depends on / blocked
 
Reported: 2010-09-01 07:19 UTC by Eugene Teo (Security Response)
Modified: 2011-07-20 16:57 UTC (History)
9 users (show)

Fixed In Version: kernel-2.6.32-83.el6
Doc Type: Bug Fix
Doc Text:
Prior to this update, the execve utility exhibited the following flaw. When an argument and any environment data were copied from an old task's user stack to the user stack of a newly-execve'd task, the kernel would not allow the process to be interrupted or rescheduled. Therefore, when the argument or environment string data was (abnormally) large, there was no "interactivity" with the process while the execve() function was transferring the data. With this update, fatal signals (like CTRL+c) can now be received and handled and a process is allowed to yield to higher priority processes during the data transfer.
Clone Of: 628498
Environment:
Last Closed: 2011-05-19 12:54:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0542 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 6.1 kernel security, bug fix and enhancement update 2011-05-19 11:58:07 UTC

Description Eugene Teo (Security Response) 2010-09-01 07:19:27 UTC
+++ 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.

Comment 1 Eugene Teo (Security Response) 2010-09-08 08:18:44 UTC
[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

Comment 2 Roland McGrath 2010-09-13 02:01:53 UTC
Linus merged my patches upstream.  Someone should backport them for RHEL:
commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919
commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd
commit 1b528181b2ffa14721fb28ad1bd539fe1732c583

Those are necessary to fix some failure modes (BUG_ON cases).  But they are not sufficient to avoid the potential bad OOM-kill scenarios.  Upstream patches related to that appear still to be under discussion (but I am not really involved in that, so don't ask me).

Comment 3 Dave Anderson 2010-09-24 19:38:42 UTC
Roland,

Damn -- I missed your request for the setup_arg_pages() patch request
and had just gone with Eugene's initial request for the other two patches
in my RHKL post.

Should commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 go into RHEL5
as well?

Comment 4 Roland McGrath 2010-09-25 00:28:02 UTC
There is a test case/exploit for the setup_arg_pages problem, in which anybody (unless root sets a low hard limit on RLIMIT_STACK for everybody) can provoke the BUG_ON in shift_arg_pages.  1b528181b2ffa14721fb28ad1bd539fe1732c583 is needed to fix that, and any backport should be verified against that test case (of course, after verifying a version of the test case that can in fact be made to bite the RHEL in question).  The other two patches just mitigate related issues, so e.g. you should be able to kill -9 that test case while it's chewing CPU, before it gets far enough to provoke the BUG_ON crash.  

Note that this same test case/exploit can still potentially cause a crash or misbehavior of some sort via the OOM-kill problem, even after these fixes.  There are other upstream fixes being pursued (not by me) to address that problem, which is the more difficult one.

Comment 5 Eugene Teo (Security Response) 2010-09-27 07:14:32 UTC
(In reply to comment #4)
> There is a test case/exploit for the setup_arg_pages problem, in which anybody
> (unless root sets a low hard limit on RLIMIT_STACK for everybody) can provoke
> the BUG_ON in shift_arg_pages.  1b528181b2ffa14721fb28ad1bd539fe1732c583 is
> needed to fix that, and any backport should be verified against that test case
> (of course, after verifying a version of the test case that can in fact be made
> to bite the RHEL in question).  The other two patches just mitigate related
> issues, so e.g. you should be able to kill -9 that test case while it's chewing
> CPU, before it gets far enough to provoke the BUG_ON crash.  
> 
> Note that this same test case/exploit can still potentially cause a crash or
> misbehavior of some sort via the OOM-kill problem, even after these fixes. 
> There are other upstream fixes being pursued (not by me) to address that
> problem, which is the more difficult one.

I got the bug for this, bug 625688. But I plan to split that bug into two since it addresses two issues.

Comment 6 Eugene Teo (Security Response) 2010-09-27 07:15:00 UTC
(In reply to comment #3)
> Roland,
> 
> Damn -- I missed your request for the setup_arg_pages() patch request
> and had just gone with Eugene's initial request for the other two patches
> in my RHKL post.
> 
> Should commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 go into RHEL5
> as well?

No, I will file a bug for it.

Comment 8 RHEL Program Management 2010-11-16 16:31:22 UTC
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.

Comment 9 Aristeu Rozanski 2010-11-17 19:45:32 UTC
Patch(es) available on kernel-2.6.32-83.el6

Comment 15 Martin Prpič 2011-02-23 15:06:32 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, the execve utility exhibited the following flaw. When an argument and any environment data were copied from an old task's user stack to the user stack of a newly-execve'd task, the kernel would not allow the process to be interrupted or rescheduled. Therefore, when the argument or environment string data was (abnormally) large, there was no "interactivity" with the process while the execve() function was transferring the data. With this update, fatal signals (like CTRL+c) can now be received and handled and a process is allowed to yield to higher priority processes during the data transfer.

Comment 18 errata-xmlrpc 2011-05-19 12:54:40 UTC
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-0542.html


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