First published: Mon Feb 01 2010(Updated: )
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: <a href="http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549">http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549</a> Discussions: <a href="http://marc.info/?t=126466700200002&r=1&w=2">http://marc.info/?t=126466700200002&r=1&w=2</a> Acknowledgements: Red Hat would like to thank Mathias Krause for reporting this issue.
Credit: secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Linux Linux kernel | <2.6.32.8 | |
Debian Debian Linux | =5.0 | |
Debian Debian Linux | =4.0 | |
Canonical Ubuntu Linux | =6.06 | |
Canonical Ubuntu Linux | =9.04 | |
Canonical Ubuntu Linux | =8.04 | |
Canonical Ubuntu Linux | =8.10 | |
Canonical Ubuntu Linux | =9.10 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.