current elf 0-length loading issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have run into an elf loading issue when moving a program from running with a 2.6.5-
derived SuSE kernel to the 2.6.15 kernel.org kernel. The image being loaded is admittedly
unusual, but used to work and seems to be valid.

The program header for the troublesome image is the following:

Back.t:     file format elf32-i386

Program Header:
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00135718 memsz 0x00135718 flags r-x
    LOAD off    0x00135720 vaddr 0x0817e720 paddr 0x0817e720 align 2**12
         filesz 0x0000ffbc memsz 0x0002e594 flags rw-
    LOAD off    0x00146000 vaddr 0x63c03000 paddr 0x63c03000 align 2**12
         filesz 0x00000000 memsz 0x0008134c flags rw-
    NOTE off    0x00000200 vaddr 0x08048200 paddr 0x08048200 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--
    NOTE off    0x00000220 vaddr 0x08048220 paddr 0x08048220 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rw-

Note that the third LOAD area has a filesz of 0. This causes the elf loader to
attempt to do an mmap of zero length. In the older kernel, this seemed to "work"
in that no error was generated. Now in mm/mmap.c there is a check on the length
which returns -EINVAL if the length being mapped is zero. That error currently
results in a SIGKILL before things even get started.

In case you are wondering how this image was created, this funny load section was
the result from the following lines in a custom linker script:

  . = 0x63c03000;
  PROVIDE (SHMEM_START = .);
  .shmem (NOLOAD) :  { *(.shmem) }

AFAIK, this is not an invalid thing to do. If I am wrong about that, please
let me know.

I have created a patch that allows this image to be successfully run. This patch
attempts to tread lightly on the source by only modifying the existing error path.
It might be better to check for the zero length to avoid making the doomed elf_map
call. Depending on the response to this message, I will submit any resulting patch
in a proper form later.

From: Mark Rustad <[email protected]>

Allow zero-length load sections once again. They stopped working when do_mmap
began failing 0-length mappings.

Signed-off-by: Mark Rustad <[email protected]>
---

--- a/fs/binfmt_elf.c	2006-01-02 21:21:10.000000000 -0600
+++ b/fs/binfmt_elf.c	2006-02-02 10:03:05.686253489 -0600
@@ -842,8 +842,11 @@ static int load_elf_binary(struct linux_
 
 		error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt, elf_prot, elf_flags);
 		if (BAD_ADDR(error)) {
-			send_sig(SIGKILL, current, 0);
-			goto out_free_dentry;
+			if (elf_ppnt->p_filesz) {
+				send_sig(SIGKILL, current, 0);
+				goto out_free_dentry;
+			}
+			error = ELF_PAGESTART(load_bias + vaddr);
 		}
 
 		if (!load_addr_set) {
-- 
Mark Rustad, [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux