Description of problem: When an application has a stack overflow, the stack could silently overwrite other memory mapped area instead of causing a segmentation fault. Acknowledgements: Red Hat would like to thank the X.Org security team for reporting this issue. Upstream acknowledges Rafal Wojtczuk as the original reporter.
Linus has committed a fix for this issue: http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893
Fixed in 2.6.32.19, 2.6.34.4 and 2.6.35.2. Fixes are in the review stage for 2.6.27.52
(In reply to comment #24) > Linus has committed a fix for this issue: > http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893 We also need: http://git.kernel.org/linus/5528f9132cf65d4d892bcbc5684c61e7822b21e9 http://git.kernel.org/linus/96054569190bdec375fe824e48ca1f4e3b53dd36 http://git.kernel.org/linus/11ac552477e32835cb6970bf0a70c210807f5673 http://git.kernel.org/linus/d7824370e26325c881b665350ce64fb0a4fde24a http://git.kernel.org/linus/05fa199d45c54a9bda7aa3ae6537253d6f097aa9 (in rhel6)
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2010:0631 https://rhn.redhat.com/errata/RHSA-2010-0631.html
From the reporter, Blog: http://theinvisiblethings.blogspot.com/2010/08/skeletons-hidden-in-linux-closet.html Paper: http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf It was reported that this can be exploited with an X server. It is possible to mitigate this by disabling MIT-SHM extension as indicated in section 3.2 of the provided paper. However, this workaround is only applied to this specific scenario.
All the fixes are queued as of 2.6.27.52-rc3, 2.6.32.20-rc1, 2.6.34.5-rc1 and 2.6.35.3-rc1. They're also in the latest F12, 13 and 14 updates submitted for testing.
Three more patches related to the stack guard page have been added: http://git.kernel.org/linus/297c5eee372478fc32fec5fe8eed711eedb13f3d http://git.kernel.org/linus/7798330ac8114c731cfab83e634c6ecedaa233d7 http://git.kernel.org/linus/0e8e50e20c837eeec8323bba7dcd25fe5479194c
Is this resolved in the current RHEL5 kernel?
RHEL4?
(In reply to comment #47) > Is this resolved in the current RHEL5 kernel? (In reply to comment #49) > RHEL4? Not yet to both. We are working on updates to address this issue. As you can see in comment #43, there are additional fixes available two days ago, that we will also need to backport for issues found in the official fixes. Thanks.
Is there an ETA on a fix? We are getting quite nervous.
This issue has been addressed in following products: Red Hat Enterprise Linux 5.3.Z - Server Only Via RHSA-2010:0660 https://rhn.redhat.com/errata/RHSA-2010-0660.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0661 https://rhn.redhat.com/errata/RHSA-2010-0661.html
Reading the original paper http://cansecwest.com/core05/memory_vulns_delalleau.pdf, it seems that guard pages may be inadequate, especially if programs are compiled without gcc -fstack-check, as applications can control their own stack pointer. Linus' commit 320b2b8de12698082609ebbc1a17165727f4c893 says it's a minimal patch to add a guard page below a grow-down stack segment. Am I missing something ? Should X be recompiled with -fstack-check ?
(In reply to comment #57) > Reading the original paper > http://cansecwest.com/core05/memory_vulns_delalleau.pdf, it seems that guard > pages may be inadequate, especially if programs are compiled without gcc > -fstack-check, as applications can control their own stack pointer. > > Linus' commit 320b2b8de12698082609ebbc1a17165727f4c893 > says it's a minimal patch to add a guard page below a grow-down stack segment. > > Am I missing something ? Should X be recompiled with -fstack-check ? For the userspace, please follow-up in bug 615330. Thanks.
This issue has been addressed in following products: Red Hat Enterprise Linux 5.4.Z - Server Only Via RHSA-2010:0670 https://rhn.redhat.com/errata/RHSA-2010-0670.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2010:0676 https://rhn.redhat.com/errata/RHSA-2010-0676.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4.7 Z Stream Via RHSA-2010:0677 https://rhn.redhat.com/errata/RHSA-2010-0677.html
kernel 2.6.18-194.11.3.el5 x86_64 described in RHSA-2010:0661 https://rhn.redhat.com/errata/RHSA-2010-0661.html appears to still be vulnerable.
Sorry, looks like the issue I'm seeing is CVE-2010-3081 not CVE-2010-2240. please ignore my previous comment.
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Extended Lifecycle Support Via RHSA-2010:0882 https://rhn.redhat.com/errata/RHSA-2010-0882.html