[PATCH] fs/binfmt_elf.c:load_elf_binary() doesn't verify interpreter arch

From: Peter Bergner <bergner@vnet.ibm.com>

In fs/binfmt_elf.c:load_elf_binary() (both 2.6 and 2.4), there is some
minimal checking whether the interpreter it's about to load/run is a valid
ELF file, but it fails to check whether the interpreter is of the correct
arch.  We ran into this when a borked powerpc64-linux toolchain set the
interpreter on our 64-bit app to our 32-bit ld.so.  Executing the app
caused the kernel to really chew up memory.  I'm assuming x86_64 and
sparc64 might possibly see the same behavior.

Note I'm not sure of the history behind INTERPRETER_AOUT, so I added the
test for INTERPRETER_ELF so as not to change it's behavior in case someone
still relies on it.

As an aside, it seems the elf_check_arch() macros should really be checking
for more than a valid e_machine value.  I'd think checking one or more of
the e_ident[EI_CLASS], e_ident[EI_DATA] and e_ident[EI_OSABI] values would
be required as well, no?

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 30127be7533bae69b4064c97e7b7a19453dcdd8f..969fdbbba9d449237054f85c7d4366c0e9a9898d 100644 (file)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -602,6 +602,10 @@ static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs * regs)
                        // printk(KERN_WARNING "ELF: Ambiguous type, using ELF\n");
                        interpreter_type = INTERPRETER_ELF;
                }
+               /* Verify the interpreter has a valid arch */
+               if ((interpreter_type == INTERPRETER_ELF) &&
+                   !elf_check_arch(&interp_elf_ex))
+                       goto out_free_dentry;
        } else {
                /* Executables without an interpreter also need a personality  */
                SET_PERSONALITY(elf_ex, ibcs2_interpreter);