Bug 560547 (CVE-2010-0307)

Summary: CVE-2010-0307 kernel: DoS on x86_64
Product: [Other] Security Response Reporter: Eugene Teo (Security Response) <eteo>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: arozansk, bhu, davej, dfeng, dhoward, eren, jolsa, jpirko, jskrabal, kmcmartin, lgoncalv, lwang, 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:55:53 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: 547593, 560549, 560550, 560551, 560552, 560553, 579408, 586024    
Bug Blocks:    
Attachments:
Description Flags
Public reproducer none

Description Eugene Teo (Security Response) 2010-02-01 05:06:29 UTC 
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 05:18:25 UTC 
Created attachment 387971 [details]
Public reproducer
Comment 3 Eugene Teo (Security Response) 2010-02-01 05:21:15 UTC 
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 19:40:40 UTC 
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 06:45:46 UTC 
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 17:12:55 UTC 
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-05 01:47:49 UTC 
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 22:15:23 UTC 
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 13:18:51 UTC 
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-17 00:17:23 UTC 
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-18 02:22:49 UTC 
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-17 00:47:07 UTC 
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 18:49:39 UTC 
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 15:30:30 UTC 
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