Bug 629178
Summary: | kernel: Problem with execve(2) reintroduced [rhel-6.1] | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Eugene Teo (Security Response) <eteo> |
Component: | kernel | Assignee: | Dave Anderson <anderson> |
Status: | CLOSED ERRATA | QA Contact: | Caspar Zhang <czhang> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | arozansk, cebbert, davej, dhoward, eteo, kmcmartin, lwang, qcai, roland |
Target Milestone: | rc | Keywords: | ZStream |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | 628498 | Environment: | |
Last Closed: | 2011-05-19 12:54:40 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: | 628498, 629179, 629180 | ||
Bug Blocks: | 629176, 661731 |
Description
Eugene Teo (Security Response)
2010-09-01 07:19:27 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 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). 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? 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. (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. (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. 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. Patch(es) available on kernel-2.6.32-83.el6 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. 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 |