Bug 515392 (CVE-2009-2847)
| Summary: | CVE-2009-2847 kernel: information leak in sigaltstack | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Eugene Teo (Security Response) <eteo> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bhu, davej, dhoward, jlieskov, jolsa, jpirko, jskrabal, kyle, lgoncalv, lwang, onestero, pmatouse, tcallawa, vgoyal, williams |
| 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: | 2012-03-28 08:47:39 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: | 515393, 515394, 515395, 515396, 515397 | ||
| Bug Blocks: | |||
Reproducer: http://milw0rm.com/exploits/9352 MITRE's CVE-2009-2847 entry: ---------------------------- The do_sigaltstack function in kernel/signal.c in Linux kernel 2.6 before 2.6.31-rc5, when running on 64-bit systems, does not clear certain padding bytes from a structure, which allows local users to obtain sensitive information from the kernel stack via the sigaltstack function. References: ----------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2847 http://www.milw0rm.com/exploits/9352 http://www.openwall.com/lists/oss-security/2009/08/04/1 http://www.openwall.com/lists/oss-security/2009/08/05/1 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0083fc2c50e6c5127c2802ad323adf8143ab7856 kernel-2.6.29.6-217.2.16.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-217.2.16.fc11 kernel-2.6.29.6-217.2.16.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2009:1239 https://rhn.redhat.com/errata/RHSA-2009-1239.html This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2009:1239 https://rhn.redhat.com/errata/RHSA-2009-1239.html This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1243 https://rhn.redhat.com/errata/RHSA-2009-1243.html This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1243 https://rhn.redhat.com/errata/RHSA-2009-1243.html This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1243 https://rhn.redhat.com/errata/RHSA-2009-1243.html This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009:1438 https://rhn.redhat.com/errata/RHSA-2009-1438.html This issue has been addressed in following products: Red Hat Enterprise Linux 5.3.Z - Server Only Via RHSA-2009:1466 https://rhn.redhat.com/errata/RHSA-2009-1466.html kernel-2.6.27.35-170.2.94.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.27.35-170.2.94.fc10 kernel-2.6.27.35-170.2.94.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: do_sigaltstack: avoid copying 'stack_t' as a structure to user space Ulrich Drepper correctly points out that there is generally padding in the structure on 64-bit hosts, and that copying the structure from kernel to user space can leak information from the kernel stack in those padding bytes. Avoid the whole issue by just copying the three members one by one instead, which also means that the function also can avoid the need for a stack frame. This also happens to match how we copy the new structure from user space, so it all even makes sense. Upstream commit: http://git.kernel.org/linus/0083fc2c50e6c5127c2802ad323adf8143ab7856