Bug 560547 - (CVE-2010-0307) CVE-2010-0307 kernel: DoS on x86_64
CVE-2010-0307 kernel: DoS on x86_64
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
reported=20100128,source=lkml,public=...
: Security
Depends On: 547593 560549 560550 560551 560552 560553 579408 586024
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-01 00:06 EST by Eugene Teo (Security Response)
Modified: 2015-02-16 10:48 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-28 04:55:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Public reproducer (796 bytes, application/x-compressed-tar)
2010-02-01 00:18 EST, Eugene Teo (Security Response)
no flags Details

  None (edit)
Description Eugene Teo (Security Response) 2010-02-01 00:06:29 EST
Description of problem:
The problem seams to be located in fs/binfmt_elf.c:load_elf_binary(). It calls SET_PERSONALITY() prior checking that the ELF interpreter is available. This in turn makes the previously 32 bit process a 64 bit one which would be fine if execve() would succeed. But after the SET_PERSONALITY() the open_exec() call fails (because it cannot find the interpreter) and execve() almost instantly returns with an error. If you now look at /proc/PID/maps you'll see, that it has the vsyscall page mapped which shouldn't be. But the process is not dead yet, it's still running. By now generating a segmentation fault and in turn trying to generate a core dump the kernel just dies.

Steps to Reproduce:
1. Enable core dumps
2. Start an 32 bit program that tries to execve() an 64 bit program
3. The 64 bit program cannot be started by the kernel because it can't find the
interpreter, i.e. execve returns with an error
4. Generate a segmentation fault
5. panic

(EDIT: This is triggerable on 2.6.31.9-174.fc12.x86_64).

Upstream commit:
http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549

Discussions:
http://marc.info/?t=126466700200002&r=1&w=2

Acknowledgements:

Red Hat would like to thank Mathias Krause for reporting this issue.
Comment 2 Eugene Teo (Security Response) 2010-02-01 00:18:25 EST
Created attachment 387971 [details]
Public reproducer
Comment 3 Eugene Teo (Security Response) 2010-02-01 00:21:15 EST
Related patches:
x86: get rid of the insane TIF_ABI_PENDING bit
http://git.kernel.org/linus/05d43ed8a89c159ff641d472f970e3f1baa66318
sparc: TIF_ABI_PENDING bit removal
http://git.kernel.org/linus/94673e968cbcce07fa78dac4b0ae05d24b5816e1
Comment 5 Chuck Ebbert 2010-02-01 14:40:40 EST
All the fixes for this are queued for 2.6.32.8:

  split-flush_old_exec-into-two-functions.patch
  x86-get-rid-of-the-insane-tif_abi_pending-bit.patch
  sparc-tif_abi_pending-bit-removal.patch
Comment 6 Danny Feng 2010-02-02 01:45:46 EST
I don't think we need sparc part for rhel ;-)
But there might be new commits for other archs:

powerpc: TIF_ABI_PENDING bit removal
commit: 94f28da8409c6059135e89ac64a0839993124155
Comment 7 Fedora Update System 2010-02-03 12:12:55 EST
kernel-2.6.30.10-105.2.13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.10-105.2.13.fc11
Comment 10 Fedora Update System 2010-02-04 20:47:49 EST
kernel-2.6.30.10-105.2.13.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2010-02-09 17:15:23 EST
kernel-2.6.31.12-174.2.17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.31.12-174.2.17.fc12
Comment 12 Fedora Update System 2010-02-16 08:18:51 EST
kernel-2.6.31.12-174.2.19.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Chuck Ebbert 2010-02-16 19:17:23 EST
Also needs:

http://marc.info/?l=linux-kernel&m=126636290420589&q=raw

Without the above, the boot option "noexec32=off" does not work.
Comment 14 Eugene Teo (Security Response) 2010-02-17 21:22:49 EST
Thanks Chuck.

Please ensure we backport:
 - 221af7f87 ("Split 'flush_old_exec' into two functions")
 - 05d43ed8a ("x86: get rid of the insane TIF_ABI_PENDING bit")
 - 7ab02af42 ("Fix 'flush_old_exec()/setup_new_exec()' split")
 - 94f28da84 ("powerpc: TIF_ABI_PENDING bit removal")
 - 1252f238d ("x86: set_personality_ia32() misses force_personality32")

Thanks.
Comment 15 errata-xmlrpc 2010-03-16 20:47:07 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0146 https://rhn.redhat.com/errata/RHSA-2010-0146.html
Comment 17 errata-xmlrpc 2010-05-06 14:49:39 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0398 https://rhn.redhat.com/errata/RHSA-2010-0398.html
Comment 19 errata-xmlrpc 2010-10-14 11:30:30 EDT
This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2010:0771 https://rhn.redhat.com/errata/RHSA-2010-0771.html

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